Change Requests | OGC

(1)

Open Geospatial Consortium

OGC Doc 08-112

CR-Form-v3

CHANGE REQUEST



_{GML CR 08-112}

 rev

_-

 Current version: 3.2.1 

For

HELP

on using this form, see bottom of this page or look at the pop-up text over the symbols.

Proposed change affects:  AS Imp Spec X Best Practices Paper Other

Title:  GML encoding rule for UML "redefine"

Source:  CSIRO

Work item code:  Date:  2008-08-03

Category:  B

Use one of the following categories:

F (Critical correction)

A (corresponds to a correction in an earlier release)

B (Addition of feature),

C (Functional modification of feature)

D (Editorial modification)

Detailed explanations of the above categories can be found in the TC Policies and Procedures.

Reason for change:  _{Standard UML modelling allows for a class specialization to redefine a class}

attribute or association so that the type or target class is a specialization of that on the parent. While XML Schema provides similar capability through its "restriction" form of type derivation, this is syntactically clumsy, error prone, and cannot be used for to override the definition of locally scoped elements originally defined in another namespace. Schematron constraints provide a practical alternative, and an encoding rule may be defined to apply these.

Summary of change:  _{The rule requires two steps:}

1. where an attribute or role is intended to redefine one originally defined on a parent class, this should be indicated in the model using a tagged value "ownedBy" that names the package where it was originally defined.

NOTE This step is not strictly necessary in UML when the whole model, including externally governed packages, are available. However, when a single package representing an Application Schema is exported in XMI for encoding, the details of content of the external dependencies (including class attributes and associations) are not exported. Thus an encoder cannot know (a) that the property is being redefined, and (b) in what namespace the property was originally defined.

2. Creation of a Schematron rule that restricts the property value, as follows:

<sch:rule context="nns:Class2">

<sch:assert test="ons:roleA/ens:Class4 or count(ons:roleA/*) = 0"

(2)

The OGC Technical Committee Policies & Procedures 05-020r3 </sch:rule>

In Annex E the following encoding rule should be added:

If



an attribute or association role ("property")

foo

has a tagged value

ownedBy="OriginalPackage"

,

 foo

is owned by a class

Bar

which has the stereotype «Type»,

«FeatureType», or «DataType»

where

 foo

and

Bar

are owned by

NewPackage

, which has

targetNamespace="New_namespace"

 foo

has the type/target-class

Baz

owned by

ExternalPackage

,

which has

targetNamespace="External_namespace"

 OriginalPackage

identifies a package which has

targetNamespace="Original_namespace"

then

1. do not generate an XML element for

foo

in the content model for

Bar

2. and one of

o

if

foo

does not carry a tagged value

inlineOrByReference

or the tagged value

inlineOrByReference="inlineOrByReference"

(default),

and

Baz

has the stereotype «Type» or «FeatureType» or

«Union», generate a Schematron

assert

statement as follows

<sch:schema

xmlns:sch="http://purl.oclc.org/dsdl/schematron">

<sch:title>Schematron constraints for Bar</sch:title> <sch:ns prefix="sch"

uri="http://purl.oclc.org/dsdl/schematron"/>

<sch:ns prefix="ons" uri="Original_namespace"/> <sch:ns prefix="nns" uri="New_namespace"/> <sch:ns prefix="ens" uri="External_namespace"/> <sch:pattern name="Property redefined">

<sch:rule context="nns:Bar">

<sch:assert test="ons:foo/ens:Baz or count(ons:foo/*) = 0"

>foo must contain either Baz or nothing (and carry an xlink:href instead)</sch:assert> </sch:rule>

</sch:pattern> </sch:schema>

o

if the tagged value

inlineOrByReference="inline"

, or if

Baz

has the stereotype «DataType», generate a Schematron

assert

statement as follows

<sch:schema

(3)

The OGC Technical Committee Policies & Procedures 05-020r3

<sch:assert test="ons:foo/ens:Baz">foo must contain Baz</sch:assert>

</sch:rule> </sch:pattern> </sch:schema>

o

if the tagged value

inlineOrByReference="byReference"

,

generate a Schematron

assert

statement as follows

<sch:schema

<sch:assert test="count(ons:foo/*) = 0"

>foo must contain nothing (and carry an xlink:href instead)</sch:assert>

</sch:rule> </sch:pattern> </sch:schema>

Consequences if 

not approved: Not possible to encode specializations of classes that include redefines

Clauses affected:  8.1, 7.2.3.8, E

Other specs  Other core specifications 

Affected: Abstract specifications

Best Practices Document Supporting Doc. 

Other comments:  Status 

Disposition 

How to create CRs using this form: Comprehensive

information and tips about how to create CRs can be found at:

https://portal.open geospatial.org/files /?

(4)

The OGC Technical Committee Policies & Procedures 05-020r3

artifact_id=10678. Below is a brief summary:

Fill out the above form. The symbols above marked 

contain pop-up help information about the field that they are closest to.

Obtain the latest version for the release of the specification to which the change is proposed. Use the MS Word "revision marks" feature (also known as "track changes") when making the changes. All Open GIS specifications can be downloaded from the OGC server under

http://www.opengeospa tial.org/specs/

If a Word version of the document is not available, please contact the TCC or his designee.

With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specification just in front of the clause containing the first piece of changed text. Delete those parts of the specification that are not relevant to the change request.