"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Converting a UML model to a GML Application Schema

Warning: This topic describes a superseded version of the rules for converting an application schema from UML to GML
The standard rules are provided in ISO 19136:2007 (GML 3.2.1) Annex E and illustrated by the models in UmlGmlTestModels

Contents

Related pages



Context

This recipe describes a restricted version of the UML-GML patterns described in the GML specification. The restrictions cover aspects of both the UML profile to be used, and the way that it is serialised in XML. These are intended to reduce variability in modelling patterns available, while not reducing the expressiveness of the schema.

UML profile for GML application schemas

A model intended to be implemented as an XML Schema following the GML pattern is specified in a UML static class diagram conforming to the SchemaFormalization#GML_Profile_of_UML. The profile includes the following constraints:

  1. Single inheritance
    • except for inheritance stereotyped <<realize>> from a parent class stereotyped <<interface>>
  2. roleName on all navigable association ends
  3. the default cardinality for a navigable association end is [0..*] (ISO 19103 Clause 6.9.1)
  4. the default cardinality for an attribute is [1]
  5. Classes carry stereotypes and tagged values as specified in Annex E of GML 3.2 and summarized in SchemaFormalization#ISO_TC_211_Profile_of_UML.
    • Any class without a stereotype is implicitly <<FeatureType>>
  6. On a class stereotyped <<Union>> all attributes have cardinality [1..1]
  7. An association with a class stereotyped <<Union>> is unidirectional towards the Union class
  8. Class operations not used
  9. No direct use of OCL constraints (to represent derivation by restriction)

In addition, the following conventions are recommended:

  1. Class names are in UpperCamelCase
  2. Attributes and roleNames are in lowerCamelCase
  3. Avoid use of XML specific stereotypes and tags to reduce impact on other implementations

UML 2 GMLAS recipe

Packaging

For each package with the stereotype <<Leaf>> create a skeleton schema document packageName.xsd following pattern 0
  1. replace "tns" with the value tagged "xmlns" from the parent package stereotyped <<Application Schema>>
  2. replace "targetNamespaceName" with the value tagged "targetNamespace" from the parent package stereotyped <<Application Schema>>
  3. for each Dependency link between this package and a <<Leaf>> package not within the same <<Application Schema>> package:
    1. set "ens" to the value tagged "xmlns" on the external package or its parent <<Application Schema>>
    2. set "externalNamespaceName" to the value tagged "targetNamespace" on the external package or its parent <<Application Schema>>
    3. set "importSchemaPath" to the value tagged "xsdDocument" on the external package
    4. add a namespace declaration to the <schema> element 'xmlns:$ans$="$externalNamespaceName$"'
    5. add an <import> element as shown
  4. for each Dependency link between this package and a <<Leaf>> package within the same <<Application Schema>> package:
    1. set "includeSchemaPath" to the value tagged "xsdDocument" on the package dependency target
    2. add an <include> element as shown

Schema components

Within this schema document insert the following:

For each class "Class1", which is a member of this package, with no stereotype or <<FeatureType>>, <<ObjectType>> or <<ObjectType>>
  1. add a global type representing the structure or content model for instances of class,
    • using
      • pattern 1a if there is a parent class "Class2" (required if no stereotype or <<FeatureType>> or <<ObjectType>>)
      • pattern 1b if there is no parent
    • the local element declarations should be repeated for all attributes and traversible associations
      • the "attribute1Name" pattern is used where the type of the class attribute is a class stereotyped <<PrimitiveType>>, <<BasicType>> or is a builtin datatype
      • the "attribute2Name" pattern is used where the type of the class attribute is any other class
      • the "attribute3Name" pattern is used where the class attribute has the value tagged xmlAttribute set "true"
        • set use="required" if the cardinality in the model is [1]
      • the "associationRole1Name" pattern is used for traversible associations where the association has a value tagged inlineOrByReference set "byReference"
      • the "associationRole2Name" pattern is used for traversible associations where the association has a value tagged inlineOrByReference not set "byReference"
      • the "ans:$Class4$Group" and "ans:$Class4$AttributeGroup" patterns are used to implement inheritance stereotyped <<realize>> from a parent class stereotyped <<interface>>
      • the values of the cardinality constraints minOccurs and maxOccurs should match the model
  2. add a global element declaration representing instances of class, using
    • pattern 2a if there is a parent class "Class2" (required if no stereotype or <<FeatureType>> or <<ObjectType>>)
    • pattern 2b if there is no parent.
    • set abstract="true" if appropriate
  3. if the value tagged noPropertyType is missing or set "false", add a global type for use in associations involving instances of the class, using
    • pattern 3a if the value tagged byValuePropertyType is missing or set "false"
    • pattern 3b if the value tagged byValuePropertyType is set "true"

For each class in the package stereotyped <<Union>>
  1. add a global type for use in associations using pattern 4.
    • the subelements and enumeration values are paired, corresponding to the attributeName/type pairs in the model
    • the XML subelement uses/attributes uses are repeated for all attributes of the Union class

For each class "Class5" in the package stereotyped <<interface>>
  1. add a global content model group using pattern 5a.
    • the "attributei1Name" pattern is used where the "type" of the class attribute is a class stereotyped <<PrimitiveType>>, <<BasicType>> or is a builtin datatype
    • the "attributei2Name" pattern is used where the "type" of the class attribute is any other class
  2. add a global attribute group using pattern 5b.
    • for the set of class attributes on which the value tagged xmlAttribute set "true"
      • set use="required" if the cardinality in the model is [1]

XML Schema patterns

  • tns == target namespace prefix
  • ens == external namespace prefix
  • ans == appropriate namespace prefix - either local or external as required
  • $Token$ == variable name

The rules above refer to the following XML schema patterns:

0. Schema document

<schema targetNamespace="targetNamespaceName" elementFormDefault="qualified" 
         xmlns:xlink="http://www.w3.org/1999/xlink" 
         xmlns:gml="http://www.opengis.net/gml" 
         xmlns="http://www.w3.org/2001/XMLSchema" 
         xmlns:tns="targetNamespaceName" 
         xmlns:ens="externalNamespaceName">
   <import namespace="externalNamespaceName" schemaLocation="importSchemaPath" />
   <include schemaLocation="includeSchemaPath" />
</schema>

1a. Class structure pattern - with parent

<complexType name="$Class1$Type">
   <complexContent>
      <extension base="ans:$Class2$Type">
         <sequence>
            <group ref="ans:$Class3$Group"/>
            <element name="$attribute1Name$" 
                     type="ans:$Attribute1Type$" 
                     minOccurs="i" maxOccurs="j"/>
            <element name="$attribute2Name$" 
                     type="ans:$Class4$PropertyType" 
                     minOccurs="k" maxOccurs="l"/>
            <element name="$associationRole1Name$" 
                     type="ans:$Class5$PropertyType" 
                     minOccurs="m" maxOccurs="n"/>
            <element name="$associationRole2Name$" 
                     type="gml:ReferenceType" 
                     minOccurs="o" maxOccurs="p"/>
         </sequence>
         <attribute name="$attribute3Name$" 
                    type="ans:$Attribute3Type$" 
                    use="required|optional"/>
         <attributeGroup ref="ans:$Class3$AttributeGroup"/>
      </extension>
   </complexContent>
</complexType>

Note that in this pattern all "gml property" elements have local element declarations referring to global type definitions.

1b. Class structure pattern - no parent present

<complexType name="$Class1$Type">
    <sequence>
        <element name="$attributep1Name$" 
                 type="ans:$Attribute1Type$" 
                 minOccurs="i" maxOccurs="j"/>
        <element name="$attributep2Name$" 
                 type="ans:$Class4$PropertyType" 
                 minOccurs="k" maxOccurs="l"/>
        <element name="$associationRole1Name$" 
                 type="ans:$Class5$PropertyType" 
                 minOccurs="m" maxOccurs="n"/>
        <element name="$associationRole2Name$" 
                 type="gml:ReferenceType" 
                 minOccurs="o" maxOccurs="p"/>
    </sequence>
     <attribute name="$attributep3Name$" 
                 type="ans:$Attribute3Type$" 
                 use="required|optional"/>
</complexType>

Note that in this pattern, all "gml property" elements have local element declarations referring to global type definitions.

2a. Class element pattern - with parent

<element name="$Class1$" 
         type="tns:$Class1$Type" 
         substitutionGroup="ans:$Class2$"/>

2b. Class element pattern - no parent

<element name="$Class1$" 
         type="tns:$Class1$Type"/>

3a. Class association pattern - inline or by-reference

<complexType name="$Class1$PropertyType">
   <sequence minOccurs="0">
      <element ref="tns:$Class1$"/>
   </sequence>
   <attributeGroup ref="gml:AssociationAttributeGroup"/>
</complexType>

3b. Class association pattern - inline only

<complexType name="$Class1$PropertyType">
   <sequence>
      <element ref="tns:$Class1$"/>
   </sequence>
</complexType>

4. Class association pattern - target stereotyped <<Union>>

N.B. this is a variation from the encoding rule defined in Annex E of ISO 19136:2007.

<complexType name="$Class4$PropertyType">
   <sequence minOccurs="0">
      <group ref="ans:$Class4$"/>
   </sequence>
   <attributeGroup ref="gml:AssociationAttributeGroup"/>
   <attribute name="unionSemantics" type="ans:$Class4$UnionSemantics"/>
</complexType> 

<group name="$Class4$">
   <choice>
      <element ref="ans:$Class8$"/>
      <element ref="ans:$Class9$"/>
   </choice>
</group>

<simpleType name="$Class4$UnionSemantics">
   <restriction base="xs:string">
      <enumeration value="$attributeu1Name$"/>
      <enumeration value="$attributeu2Name$"/>
   </restriction>
</simpleType>

Note that in this pattern the members of the choice group that implements the Union are references to global elements declared elsewhere.

5a. Class structure pattern - stereotyped <<interface>> - XML element content

N.B. this is an experimental pattern and the <<interface>> stereotype is not recognised in Annex E of ISO 19136:2007. Proposed revisions to ISO 19118 have introduced an almost identical pattern for implementing multiple-inheritance, utilising the sequenceNumber tagged value to mark parent classes that are not substitutability parents.
<group name="$Class5$Group">
    <sequence>
        <element name="$attributei1Name$" 
                 type="ans:$Attribute1Type$" 
                 minOccurs="i" maxOccurs="j"/>
        <element name="$attributei2Name$" 
                 type="ans:$Class7$PropertyType" 
                 minOccurs="k" maxOccurs="l"/>
    </sequence>
</complexType>

Note that in this pattern all "gml property" elements have local element declarations referring to global type definitions.

5b. Class structure pattern - stereotyped <<interface>> - XML attribute content

<attributeGroup name="$Class5$AttributeGroup">
    <attribute name="$attributei3Name$" 
               type="ans:$Attribute3Type$" 
               use="optional"/>
</attributeGroup>

Complete Example

Example structure diagrams

  • Example UML packaging to illustrate UmL2GMLAS given on this page:
    Example packaging

  • Example UML model to illustrate UmL2GMLAS given on this page:
    Example UML model

<xs:schema targetNamespace="http://www.seegrid.csiro.au/xml/sa"
           xmlns:xs="http://www.w3.org/2001/XMLSchema" 
           xmlns:sa="http://www.seegrid.csiro.au/xml/sa" 
           xmlns:meta="http://www.seegrid.csiro.au/xml/metaLite" 
           xmlns:geo="http://www.seegrid.csiro.au/xml/geometry" 
           xmlns:om="http://www.opengis.net/om" 
           xmlns:gml="http://www.opengis.net/gml" 
           xmlns:xs="http://www.w3.org/2001/XMLSchema" 
           elementFormDefault="qualified">

   <xs:import namespace="http://www.seegrid.csiro.au/xml/metaLite" schemaLocation="./meta4site.xsd"/>
   <xs:import namespace="http://www.seegrid.csiro.au/xml/geometry" schemaLocation="./geo4site.xsd"/>
   <xs:import namespace="http://www.opengis.net/om" schemaLocation="./om4site.xsd"/>
   <xs:import namespace="http://www.opengis.net/gml" schemaLocation="./gml4site.xsd"/>
   <xs:include schemaLocation="./procedureEvent.xsd"/>
   <xs:include schemaLocation="./surveyProcedure.xsd"/>

   <xs:complexType name="AreaOfInterestType">
      <xs:complexContent>
         <xs:extension base="sa:SiteType">
            <xs:sequence>
               <xs:element name="area" 
                           type="gml:MeasureType" 
                           minOccurs="0"/>
               <xs:element name="shape" 
                           type="geo:Shape2DPropertyType"/>
            </xs:sequence>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>
   <xs:element name="AreaOfInterest" 
               type="sa:AreaOfInterestType" 
               substitutionGroup="sa:Site"/>

   <xs:complexType name="SiteType">
      <xs:complexContent>
         <xs:extension base="gml:AbstractFeatureType">
            <xs:sequence>
               <xs:group ref="sa:TestInterfaceClassGroup"/>
               <xs:element name="surveyDetails" 
                           type="sa:SurveyProcedurePropertyType" 
                           minOccurs="0"/>
               <xs:element name="relatedObservation" 
                           type="om:AbstractObservationPropertyType" 
                           minOccurs="0" maxOccurs="unbounded"/>
               <xs:element name="member" 
                           type="sa:SitePropertyType"/>
            </xs:sequence>
            <xs:attributeGroup ref="sa:TestInterfaceClassAttributeGroup"/>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>
   <xs:element name="Site" 
               type="sa:SiteType" 
               substitutionGroup="gml:AbstractFeature"/>

   <xs:complexType name="SitePropertyType">
      <xs:sequence minOccurs="0">
         <xs:element ref="sa:Site"/>
      </xs:sequence>
      <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
   </xs:complexType>

   <xs:group name="Shape2D">
      <xs:choice>
         <xs:element ref="gml:Polygon"/>
         <xs:element ref="gml:MultiPolygon"/>
         <xs:element ref="geo:TriSurface"/>
         <xs:element ref="geo:PlaneByVector"/>
      </xs:choice>
   </xs:group>

   <xs:simpleType name="Shape2DUnionSemantics">
      <xs:restriction base="string">
         <xs:enumeration value="polyShape"/>
         <xs:enumeration value="multiPolyShape"/>
         <xs:enumeration value="triSShape"/>
         <xs:enumeration value="planeVShape"/>
      </xs:restriction>
   </xs:simpleType>

   <xs:complexType name="Shape2DPropertyType">
      <xs:sequence minOccurs="0">
         <xs:group ref="sa:Shape2D"/>
      </xs:sequence>
      <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
      <xs:attribute name="unionSemantics" type="sa:Shape2DUnionSemantics"/>
   </xs:complexType>

   <xs:group name="TestInterfaceClassGroup">
      <xs:sequence>
         <xs:element name="att1name" 
                     type="ans:Class1PropertyType" 
                     minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
   </xs:group>

   <xs:attributeGroup name="TestInterfaceClassAttributeGroup">
      <xs:attribute name="att2name" 
                    type="ans:Type2"/>
   </xs:attributeGroup>
</xs:schema>

Not fully consistent from here on

Namespaces and modularization

XML targetNamespace for UML packages

Despite the apparent resemblance between UML packages and XML namespaces, for reasons explained in XmlXmlNamespacesAndSchemaDocuments#Namespaces the correspondence is not exact. Thus, it is safest to indicate the XML namespace explicitly, and independently of UML package identification.

For our models we apply a stereotype <<Application Schema>> to the package that comprises a complete XML Schema, and this carries tagged values "targetNamespace" and "xmlns" to provide the necessary information. Other packages may be included inside the schema package. These inherit the tagged values from the parent package.

Then in the patterns shown on this page, replace "ans" and "tns" with the prefix

How to incorporate classes from an external model/namespace

Effective schema modularization will involve dependencies on classes/elements/types that are potentially from external packages/namespaces. In the GML context the most obvious case is dependency on the GML base classes/elements/types. Dependencies fall into the following categories:
  1. class/type inheritance, appearing as
    • UML class specialization
    • XML schema element substitution group (pattern 2a.) together with type extension (pattern 1a.)
  2. complex property value, appearing as
    • UML association
    • UML attribute with type "$ClassX$"
    • XML property element declaration using a global complexType following pattern 3. "$Class3$PropertyType"
  3. simple property value, appearing as
    • UML attribute with a type stereotyped <<XSDsimpleType>> or <<BasicType>>
    • XML property element declaration using a global simpleType or complexType/simpleContent type

In order to allow the recipe to work most effectively, starting from the model of an application schema in UML, it is necessary that within the model:
  1. a UML package with the stereotype <<Application Schema>> exists for each namespace used in the model
    • the package should have the appropriate tagged value "targetNamespace"
  2. elements for all components used in the model (classes, datatypes) exist and are included in the appropriate package

The last requirement may be less onerous than appears at first sight. For any particular application schema it is almost never necessary to import all of GML, so it is not necessary for the UML model to have a complete representation of the GML model in all its detail. Since all uses of the external components are simply "by reference" within the XML Schema, it is only necessary that the components that are used exist and have the correct name. In particular,
  • there is no requirement for the parent classes to have any content or structure, since that is completely opaque for derivation by extension
  • there is no requirement to represent inheritance/generalisation relations between elements in the external namespace; all "transitive" relationships in the external namespace are invisible in the application schema.

Practical approach to managing dependencies

As a practical matter, when designing an application schema, I find that it is relatively easy to follow the following process:
  • start with an empty model
  • create a package for the targetNamespace="http://www.opengis.net/gml"
    • seed it with the following classes, representing a useful subset of GML components mostly commonly used - but don't worry about filling out their contents or interrelationships:
      • AbstractFeature
      • AbstractGeometry, Point, Envelope
      • AbstractTimeObject
      • Definition, Dictionary ...
    • seed it with some classes stereotyped <<BasicType>>, representing a useful subset of GML basicTypes - but don't worry about filling out their contents or interrelationships:
      • MeasureType
      • CodeType
      • DirectPositionType
      • VectorType ...
    • seed it with some classes stereotyped <<XSDsimpleType>>, representing a useful subset of the builtin simpleTypes provided by W3C XML Schema:
      • boolean
      • date, dateTime, time
      • double
      • integer
      • string, token ...
  • create a package(s) for the intended namespace(s) of the application schema
  • focus on building the model in the application schema package
  • if your application requires any additional classes or types from GML, add them to the GML package on an ad-hoc basis as required, but don't worry about filling out their contents or interrelationships
  • if your application requires any additional classes or types from another package/namespace, then create another package and contents in a similar way to the GML package.

XMI representations of most of the GML model and some other required packages are here: https://www.seegrid.csiro.au/subversion/xmml/trunk/model/AppSchemas.HollowWorld Use these if your UML modelling tool allows import of packages from XMI. Warning - these are work-in-progress and CSIRO provides no warranty that this is bug-free.

Limitations in comparison with previous GML usage

Choice

The patterns lead to use of XML Schema <choice> only in the implementation of classes stereotyped <<Union>>. In particular, use of choice to permit different representations of the same information is essentially eliminated: this is considered to be a Good Thing, since functionless variability is the enemy of standardization.

In practice we have found that most cases where a "choice" is genuinely needed within a content model can be expressed using this pattern, in combination with properties (UML attributes and associations) whose cardinality makes them optional. (We plan to investigate introduction of limited OCL constraint patterns to accommodate the remaining cases.)

Derivation by restriction

The major limitation concerns XML Schema derivation-by-restriction: this has been found to be implemented inconsistently in XML processing software, so the recipe described here does not use it. This XML Schema derivation-by-restriction method is one of the more distinct ways in which XML Schema varies from most other programming and development environments. For example, in UML this concept typically requires use of an OCL constraint, rather than a core UML mechanism.

Eliminating it does introduce a limitation on the schema, since a common practice in GML has been to derive specialized feature types from more general ones by restricting the values (types) of a property to a subset of the types permitted for the property on the generalized type. Essentially, the top of a derivation hierarchy in GML is often populated by classes with generalised properties that can accommodate all of the requirements of its more specialised descendants. This is a distinctly different pattern from most OO modelling, in which the high-level classes have very few properties, and the set of properties is then fleshed out in the definitions of more specialised classes.

  • Where the specialized classes have attributes that modify attributes from the parent class, this requires XML Schema derivation by restriction:
    Specialized classes have attributes that modify attributes from the parent class

In practice we have found that, within application schemas, a slightly different pattern can be used to achieve much the same outcome, but with an easier mapping to UML and other conventional modelling idioms. Instead of the "general" class being a parent of the more specialised classes, it can be modelled as a sibling. Compare this diagram with the previous one:

  • The more common idiom is where specialized classes only add attributes; the general case is now a sibling of the special cases:
    Specialized classes only add attributes; the general case is a sibling

-- SimonCox - 06 Apr 2005

EricBoisvert: First, I don't know if this page was meant to receive comments/discussion. My apologies if it was not.

I do have problems with this pattern (add only attribute) because we therefore cannot guess from the diagram if Class6 is really a sibling of Class7 or it's just a trick to deal with 'by restriction' derivation.

Why not use a stereotype to state clearly what is the intent? I proposed mustOverride as the name for the stereotype, but if you have a better name (or if UML as such a feature already). Futhermore, this small example is easy to understand, but a real life situation, you might end up with more than one attribute, some must be overidden, other not. Would be hard to tell which is which otherwise. just my 2 cents.

* mustOverride pattern:
mustOverride pattern

-- EricBoisvert - 08 Jul 2005

SimonCox: No worries Eric - intelligent discussion and challenges always welcome.

You are correct in principle of course. My reasons for avoiding the override pattern is that it requires the use of derivation-by-restriction, which is somewhat fraught in XML Schema and implemented inconsistently by processors.

I have prepared a series of examples to illustrate the problem: see XmlSchemaXmlSchemaDerivationByRestriction.

The conclusion regarding derivation by restriction is:
  1. OK where the parent type is xsd:anyType
  2. mostly OK where one element in the content model of the derived type is selected from a choice group in the parent type, or from a substitution group (implicit choice group)
  3. requires a lot of care where the type of an element in the content model of the derived type is overridden - the type used in the derived type must itself be derived by restriction from the type used in the parent type

And even when you get it right in the second two cases, the standard processors do not always agree. .NET, Xerces-J, MSXML and XSV are mostly OK, Xerces-C++ gets it wrong sometimes.

The GML Object-property pattern essentially requires that the final pattern must be used, and is thus quite tricky.

-- SimonCox - 11 Jul 2005

EricBoisvert: I cannot garantee it will always be intelligent.. :P

I do agree XmlSchemaXmlSchemaDerivationByRestriction should be avoided. We tried this route while implementing NADMC1, and it was cumbersome and made XMLSpy crash. Even in OO languages, attributes cannot be revoked, D-by-R is good for methods.

What I proposed (and 'mustOverride' is probably the wrong term) is to provide a way to document just what you propose; don't use D-by-R and reimplement a fresh copy of the attribute for all descendant without using the sibling trick.

-- EricBoisvert - 11 Jul 2005

SimonCox: OK - so the stereotype invokes a rule to
  1. check that all descendents have this property
  2. suppress the property in the XML implementation of the parent.
That is quite neat. It pushes the mess into the implementation rules, while keeping the concepts clear in the model

-- SimonCox - 11 Jul 2005

EricBoisvert:

It's pretty much what has been proposed for the Interface stereotype (implemented as an XML Group in GML).. I think... The way I understand stereotypes is that the stereotyped class or attribute should be treated in some special way, which may differ from one implementation to another. Interfaces are implemented as java interfaces in Java, as Group in XML, etc.. Stereotypes can be documented in the implementation procedures (such as this document) and direct the implementor on how to treat this special case.

it basically 'flags' the special cases.

this is what Enterprise Architect has to say about stereotype

[...]
Generally a stereotype represents a usage distinction. A stereotyped element may have additional
 constraints on it from the base metamodel class. It may also have required tagged values that add
 information needed by elements with the stereotype. It is expected that code generators and other
 tools will treat stereotyped elements specially. Stereotypes represent one of the built-in
 extensibility mechanisms of UML."
 

But maybe I over-read what stereotypes are ?

-- EricBoisvert - 11 Jul 2005

Question regarding order of properties. Since properties are modelled using xs:sequences, the order of properties in the schema is important. But this information can only be infered from the UML diagram when attributes are reported in the class as simple types, and not when the property is represented as an association between two classes. This means that 2 persons encoding the same UML into GML will end up with different schemas (differents enought for document not to validate).

I don't know if this is a real issue or not, I just wonder if there is a 'guideline' on how to interpret the order of properties from a UML diagram (beside those represented as class attributes) ? Or is the answer "the first one to code the schema sets the order".

I took the (bad) habit of coding XSLT/code directly from the UML until I realised that I code the sequences wrong and this forced me to look into schema (or did I answer my own question ?).

-- EricBoisvert - 29 May 2006

Question regarding property pattern.

Should a PropertyType be create for each class, even if such property is never used ?. For example, in GeoSciML, there are explicit properties that point to EarthMaterial and CompoundMaterial, but not directly to OrganicMaterial, which is a subtype of EarthMaterial (and we assume that an association to OrganicMaterial will be done through EarthMaterialPropertyType).

As a pattern, should we create automatically a OrganicMaterialPropertyType, for people extending the model so they can use it even if we don't, or should this be left to other group that needs this explicit (constrained) property. I'd prefer to automatically create a property because it's more systematic (you can always expect a property to exist for every class)

maybe this question is already answered somewhere (sorry if it is).

-- EricBoisvert - 24 May 2007

In answer to your question Eric, A named complex type should be created for each and every UML class with stereotype <<Type>> (or no stereotype) unless the class carries a tagged value "noPropertyType" with the value of "true" (ref: ISO19139 3.2 Annex E and committee draft of ISO19118)

regards, -- NickArdlie - 9 July 2007
Topic attachments
I Attachment Action Size Date Who Comment
TestPackage.PNGPNG TestPackage.PNG manage 6.7 K 06 Jul 2005 - 13:18 SimonCox Example packaging
TestSite.PNGPNG TestSite.PNG manage 8.4 K 06 Jul 2005 - 13:17 SimonCox Example UML model to illustrate UML2GMLAS given here
UMLexample.PNGPNG UMLexample.PNG manage 8.8 K 05 Apr 2005 - 22:04 SimonCox Example UML model matching recipe UML2GMLAS given here
restriction.GIFGIF restriction.GIF manage 4.8 K 08 Jul 2005 - 20:45 EricBoisvert mustOverride pattern
special1.PNGPNG special1.PNG manage 2.2 K 05 Apr 2005 - 22:05 SimonCox Specialized classes have attributes that modify attributes from the parent class
special2.PNGPNG special2.PNG manage 2.3 K 05 Apr 2005 - 22:05 SimonCox Specialized classes only add attributes; the general case is a sibling
Topic revision: r39 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).