Non-Standard Conversion Rules

This section describes configuration options of the input that affect the XML Schema output, but which are not conversion rules. These are treated separately as they are already processed during the initial parsing of the input model. Model elements that do not meet the selection criteria are not included in the internal model representation and are not available during the conversion to target representations.

Components with non-public visibility

By default, only model elements with public visibility are read from the model. However, this can be relaxed to include all model elements regardless of their visibility .

This is controlled by setting the publicOnly parameter of the configuration file’s <input> element to “true” or “false”.

rule-xsd-cls-adeelement

For classes with stereotype <<ADEElement>>, this conversion rule creates global CityGML property elements substitutable for the relevant _GenericApplicationPropertyOfXXX element of the CityGML supertype.

rule-xsd-cls-basictype

Basic types may be restricted with facets. For example, the length of a subtype of CharacterString may be restricted through the use of the “length” tagged value, or the allowed range of numeric values may be limited through the use of the tagged values “rangeMinimum” and “rangeMaximum”.

rule-xsd-cls-basictype-list

(since v2.11.0)

A basic type that matches this conversion rule and has a single property with maximum multiplicity greater than 1 will be converted as a list-based simple type. The list item type is the XSD type of the UML property value type. If the minimum multiplicity of the UML property is 0 and the maximum multiplicity is unbounded (‘*’), then the length of the resulting list is not restricted. Otherwise, length restrictions are defined according to the multiplicity of the property.

Example:

<<basicType>> TransformationMatrix2x2 has property list: Real [4] {sequence}

It will be encoded as:

<simpleType name=”TransformationMatrix2x2Type”>
<restriction>
<simpleType>
<list itemType=”double”/>
</simpleType>
<length value=”4″/>
</restriction>
</simpleType>

NOTE: The multiplicity order and uniqueness are ignored by the XmlSchema target. For other encodings, they could be significant (e.g. uniqueness in a JSON encoding).

rule-xsd-cls-codelist-anonymous-xlink

Properties of type codelist are represented in the GML schema as complex type with xlink simple attributes group. This is especially useful to encode such properties in GML 2.1 when codelist entries shall be referenced (note that GML 2.1 does not define a gml:CodeType or gml:ReferenceType).

rule-xsd-cls-codelist-constraints

If Schematron output is active (rule-xsd-pkg-schematron), additional constraints are added for code list values depending on several tagged values.

More information can be found in this OGC document (OWS-8 CCI Schema Automation Engineering Report).

rule-xsd-cls-codelist-constraints2

(since v2.6.0)

This rule is a revision of rule-xsd-cls-codelist-constraints that makes use of XPath 2.0 in the xslt2 query binding for Schematron (which has been standardized with ISO 19757-3:2016).

If schematron generation is enabled (via rule-xsd-pkg-schematron), then schematron assertions are created for code list typed properties. Assertions are generated based on a reference to the authoritative resource that represents the code list, and/or a specification of the code list representation. This information, together with the encoding rule that applies to the code list, controls which schematron assertions are generated.

The reference to the authoritative resource representing the code list is given via tagged value codeList on the code list.

The representation of a code list is specified via tagged value codeListRepresentation on the code list. The configuration parameter defaultCodeListRepresentation can be used to provide a global default in case that, for a given code list, the tagged value codeListRepresentation is undefined or does not have a value. This rule currently supports code list representations with the following identifiers:

• application/gml+xml;version=3.2 – A GML 3.2 dictionary (gml:Dictionary).
• application/x.iso19139+xml – An ISO 19139:2007 dictionary (gmx:CodeListDictionary or gmx:ML_CodeListDictionary).
  • NOTE: application/x.iso19139+xml is a preliminary identifier. It uses the unregistered x. Tree as defined by IETF RFC 6838 – Media Type Specifications and Registration Procedures.

• If the code list is encoded according to ISO 19139:2007, then a property type will be available for the code list. Therefore:
  • The type of the XML element that represents the code list typed property will be the property type of the code list. It has two XML attributes:
    • @codeList – A URL that references the code list definition resource. The URL may contain a fragment identifier in case that the definition is only a part of the resource (e.g. an XML file that encodes a catalog or dictionary of multiple code lists).
    • @codeListValue – The identifier of the code list value definition.
    • Example: <ex1:attribute><ex2:CodeListIso19139 codeList=”http://example.org/CodeListIso19139.xml” codeListValue=”code1″/>Code 1</ex1:attribute>
  • If tagged value codeList is defined, an assertion is created to check that the value of @codeList is equal to codeList.
  • If the code list representation is undefined, or is equal to one of the supported identifiers, an assertion is created that checks that the resource referenced by @codeList exists. The referenced resource must be available (as defined by the XPath 2.0 function doc-available) and, if @codeList contains a fragment identifier, an element must be available in the resource, having XML attribute gml:id equal to the fragment identifier.
  • If the code list representation is undefined or equal to application/gml+xml;version=3.2, two assertions are created:
    • to ensure that @codeList references a GML 3.2 dictionary, and
    • to ensure that the code list value given by @codeListValue exists, i.e. is contained in the dictionary.
  • If the code list representation is equal to application/x.iso19139+xml, two assertions are created:
    • to ensure that @codeList references an ISO 19139:2007 code list dictionary, and
    • to ensure that the code list value given by @codeListValue exists, i.e. is contained in the dictionary.
• Otherwise, if the code list valued property is encoded according to ISO 19136:2007, Annex E, then:
  • The XML element that represents the code list typed property has type gml:CodeType. The element value therefore contains the code value, while the optional @codeSpace contains the URI to the dictionary. This is quite similar to the ISO 19139 based encoding. However, the optional @codeSpace requires specific checks.
    • Example: <ex:attribute codeSpace=”http://example.org/CodeListIso19139.xml”>code1</ex:attribute>
  • If tagged value codeList is defined:
    • An assertion is created to check that @codeSpace, if set on the property element, is equal to codeList.
    • If the code list representation is undefined, or is equal to one of the supported identifiers, an assertion is created that checks that the resource referenced by @codeSpace – or, if the code space is undefined, codeList – exists. The referenced resource must be available (as defined by the XPath 2.0 function doc-available) and, if the reference contains a fragment identifier, an element must be available in the resource, having XML attribute gml:id equal to the fragment identifier.
    • If the code list representation is undefined or equal to application/gml+xml;version=3.2, two assertions are created:
      • to ensure that the code list is really represented by a GML 3.2 dictionary, and
      • to ensure that the code list value exists, i.e. is contained in the dictionary.
    • If the code list representation is equal to application/x.iso19139+xml, two assertions are created:
      • to ensure that the code list is really represented by an ISO 19139:2007 code list dictionary, and
      • to ensure that the code list value exists, i.e. is contained in the dictionary
• Otherwise, if the property is encoded according to ISO 19136-2:2015 (aka GML 3.3), 12.2, then:
  • The XML element that represents the code list typed property has type gml:ReferenceType. @xlink:href contains the URI for the dictionary item, i.e. the XML element that represents the code value. If the URI does not contain a fragment identifier (indicated by ‘#’), the referenced resource only represents the dictionary item. Otherwise, the referenced resource contains the dictionary item but the item must be looked up by its gml:id.
    • Example: <ex:attribute xlink:href=”http://example.org/CodeListIso19139.xml#code1” xlink:title=”code1”/>
  • If tagged value codeList is defined, an assertion is created to check that the URI given by @xlink:href starts with the value of codeList.
  • If the code list representation is undefined, or is equal to one of the supported identifiers, an assertion is created that checks that the referenced code list value exists. The referenced resource must be available (as defined by the XPath 2.0 function doc-available) and, if @xlink:href contains a fragment identifier, an element must be available in the resource, having XML attribute gml:id equal to the fragment identifier.
  • If the code list representation is undefined or equal to application/gml+xml;version=3.2, an assertion is created to ensure that the code value is represented by a GML 3.2 Definition element.
  • If the code list representation is equal to application/x.iso19139+xml, an assertion is created to ensure that the code value is represented by an ISO 19139:2007 CodeDefinition (or ML_CodeDefinition) element.

NOTE: Tagged value codeListValuePattern is ignored by this rule.

rule-xsd-cls-codelist-constraints-codeAbsenceInModelAllowed

Some communities have the case where a code list does not contain any code value, but still OCL constraints exist in the application schema that refer to such code values. Usually, ShapeChange reports an error if such a situation occurs, and does not create the OCL expression. However, if this rule is enabled, code list values are not required to be present in the model.

rule-xsd-cls-codelist-gmlsf

(since v2.4.0)

Encodes a property with codelist value type as specified by the GML simple features profile (OGC document number 10-100r3), section 8.4.4.14.

NOTE: This rule has originally been developed during OGC Testbed 13, to derive an XML Schema that is compliant to GML-SF level 0. For further details, see the OGC NAS Profiling Engineering Report (OGC document number 17-020r1).

rule-xsd-cls-enum-subtypes

This conversion rules includes also enumerants from subtypes in the enumeration type in XML Schema.

Note: This conversion rule is probably no longer in use and may be deleted.

rule-xsd-cls-enum-supertypes

This conversion rules includes also enumerants from supertypes in the enumeration type in XML Schema.

Note: This conversion rule is probably no longer in use and may be deleted.

rule-xsd-cls-local-basictype

Modifies the behavior of rule-xsd-cls-basictype as follows: According to rule-xsd-cls-basictype, classes identified as basic types are converted to a named simpleType (for global scope). If rule-xsd-cls-local-basictype is part of an encoding rule in addition to rule-xsd-cls-basictype, these types are converted to an anonymous simpleType for local scope.

rule-xsd-cls-local-enumeration

rule-xsd-cls-mixin-classes

Due to the fact that several implementation platforms including XML Schema support only single inheritance (type derivation from a single base type, element substitutablity in XML Schema is restricted to a single element, too), the use of multiple inheritance is currently not supported by GML 3.2 Annex E.

However, for conceptual modelling, the ability to define abstract types which capture a set of properties that are associated with a concept is sometimes very convenient.

More information…

rule-xsd-cls-mixin-classes-as-group

rule-xsd-cls-mixin-classes-non-mixin-supertypes

  <annotation>
    <appinfo source="">
      <ComplianceLevel xmlns="http://www.dgiwg.org/gml/3.2/profiles/spatial/1.0/">L1_3D</ComplianceLevel>
      <GMLProfileSchema xmlns="http://www.dgiwg.org/gml/3.2/profiles/spatial/1.0/">http://schemas.dgiwg.org/gml/3.2/spatial/1.0/3dGeometry.xsd</GMLProfileSchema>
    </appinfo>
  </annotation>
  <import namespace="http://www.dgiwg.org/gml/3.2/profiles/spatial/1.0/"/>

<element name="geometry" minOccurs="0">
 <complexType>
  <sequence minOccurs="0" maxOccurs="3">
   <element ref="gml:Point"/>
  </sequence>
 </complexType>
</element>

<element name="event" nillable="true">
 <complexType>
  <sequence maxOccurs="unbounded">
   <element ref="app:Event"/>
  </sequence>
  <attribute name="nilReason" type="gml:NilReasonType"/>
 </complexType>
</element>

<element name="role">
 <complexType>
  <sequence maxOccurs="unbounded">
   <element ref="app:Feature"/>
  </sequence>
  <attributeGroup ref="gml:OwnershipAttributeGroup"/>
 </complexType>
</element>

<element name="string">
 <simpleType>
  <list itemType="string"/>
 </simpleType>
</element>

<element name="integer" minOccurs="0">
 <simpleType>
  <list itemType="integer"/>
 </simpleType>
</element>

<attribute name="integer">
 <simpleType>
  <list itemType="integer"/>
 </simpleType>
</attribute>