Non-Standard Conversion Rules

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".

(since v2.7.0)

For each model element that is represented in the XML Schema, add the descriptors that are defined by the representDescriptors target parameter as an <sc:descriptor> annotation appInfo element. The parameter contains a comma-separated list of descriptor names (as listed here). If the parameter is not set or is empty, the rule will have no effect.

The descriptor annotations will contain the name of the descriptor and the value. If the value is given in a specific language, the language will also be indicated. Multiple values will result in multiple annotations. Example:

(since v2.5.1)

For each class or property that is represented in the XML Schema and that has a global identifier, add the value of the global identifier via an <sc:globalIdentifier> annotation appInfo element. The global identifier is one of the well-known descriptors (for further details, see here).

Instructs ShapeChange to generate schema based on GML version 2.1. The map entries and namespaces need to be configured accordingly. The encoding takes into account certain limitations of GML 2.1:

This conversion rule suppresses the conversion to XML Schema of any model elements for which the "xsdEncodingRule" tag is set to "notEncoded".

Documentation for a model element is by default exported as part of <annotation> elements in the XML Schema Document. The export of the documentation can be suppressed using this conversion rule.

(since v2.6.0)

This rule prevents the creation of a property assertion if either the property or the class for which the assertion is created is prohibited, which is currently indicated by tagged value 'prohibitedInProfile' = true.

Within an XSD <annotation>, <appinfo> elements may be used to pass information to specific applications.  ShapeChange allows selected tagged values to be mapped to <appinfo> elements of the corresponding model element.

Tagged values to be mapped in this way can be specified in the representTaggedValues parameter of the ShapeChange configuration file’s <input> element .

Example, where the "primaryCode" and "secondaryCode" tagged values were listed under representTaggedValues in the configuration file for this transformation:

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

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".

(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:

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).

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).

(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:

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.

(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.

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

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

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.

<<enumeration>> and <<codeList>> classes are by-default converted to a named simpleType (for global scope). If this conversion rule is part of an encoding rule, these types are converted to an anonymous simpleType for local scope.

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…​

Extension to rule-xsd-cls-mixin-classes that converts mixin classes to groups and references the group from the suptypes.

Extension to rule-xsd-cls-mixin-classes that allows that supertypes of a mixin type is not a mixin type. Note that this has limitations in that the non-mixin supertype property type will not support taking subtypes of the mixin type as a value.

Do not convert abstract classes to object elements and do not process their properties; create a property type with references to subtypes with object elements

Ignore base classes in the conversion process

This conversion rule suppresses the use of the base types of GML (gml:AbstractObject, gml:AbstractGMLObject, gml:AbstractFeature, but also gml:AssociationGroup) either on a general or local scope.

Supports OKSTRA <<FachID>> classes

Supports OKSTRA historisches_Objekt

Do not convert OKSTRA <<Schluesseltabelle>> classes to object elements and do not process their properties; create a OKSTRA-specific property type

(since v2.6.0)

If the direct supertype of a class is mapped to one of the ISO 19139 namespaces (http://www.isotc211.org/2005/gco, -gmd, -gmx, -gsr, -gss, -gts), then a gco:isoType attribute is added to the element that represents the class. The value of that attribute is the local name of the element to which the supertype is mapped.

This conversion rule suppresses object elements, local properties and property types, if the class has a tagged value 'suppress' with the value 'true' or a stereotype <<ADEElement>>. However, if Schematron output is active, any constraints on the class will still be included in the Schematron schema.

Do not convert union with a tagged value 'gmlAsCharacterString' set to 'true' in the usual way, but convert it as if it would be a CharacterString.

If a <<Union>> class has a tagged value "gmlAsGroup" with a value of "true", then the class is encoded as a global group which is referenced wherever a property is defined that has the union class as its value. (Note that this is only valid if it is clear from the context how to map the individual values to the conceptual model.)

A union with two properties and where one property has a tagged value 'gmlImplementedByNilReason' set to 'true' is converted as follows under this conversion rule:

A property that has the union type as its value receives the value type of the property in the union that is not implemented by nil reason as its type.

The property element is made nillable and receives a nilReason attribute.

(since v2.4.0)

A union with tagged value representsFeatureTypeSet = true is not encoded. Properties with such a union as type are encoded as elements with type gml:ReferenceType. If rule-xsd-prop-targetElement is enabled, an annotation is added with one gml:targetElement appinfo element for each feature type represented by the union.

This conversion rule adds information to the XML Schema to indicate the DGIWG Spatial Profile (DGIWGSP) compliance level.

The following tagged values must be set for an application schema that is converted to XML Schema, if the DGIWGSP information is to be included:

The resulting import and annotation in the XSD can look like this:

(since v2.4.0)

Creates a schema annotation to indicate the GML-SF compliance level as defined by the GML simple features profile (OGC document number 10-100r3), section 7.4. The compliance level is read from tagged value gmlsfComplianceLevel on the application schema. Furthermore, the rule creates an import for the gmlsfLevels.xsd, as defined by GML-SF section 8.3.2.

An application schema may contain OCL (Object Constraint Language) constraints related to the feature type or its attributes.  On the XML level, Schematron (ISO/IEC 19757-3:2006) is used in most cases to express constraints. Schematron is already used by GML to express constraints that cannot be represented in XML Schema, and is currently considered the most appropriate language to express constraints on the XML level. Tools exist to process Schematron constraints and assert the compliance of an instance document with the specified constraints, e.g. here.

ShapeChange includes a OCL 2.2 parser and Schematron code-generator, allowing for a fairly complete range of OCL expressions. The supported expressions are documented here.

The Schematron schema for an application schema is written in the same output directory as the XML Schema Document and with the same name, except that the file name ends in "_SchematronSchema.xml" instead of ".xsd".

The conversion rule uses four additional target parameters:

This conversion rule supports XsdMapEntry elements with attribute/attributeGroup mappings. This allows to reuse global attribute and attributeGroup schema components from existing XML grammars, e.g. IC-ISM.

(since v2.4.0)

Generate constraining facets based on tagged values length, maxLength, size, pattern, rangeMaximum, and rangeMinimum of a property:

By default, derived properties are included during the conversion. They can be suppressed using this conversion rule.

For properties with a tagged value 'gmlArrayProperty' set to 'true' and with complex content that is always inline, i.e. the property has the tagged value 'inlineOrByReference' set to 'inline', an array property is created instead of using the standard GML property types.

Examples:

An attribute "geometry : GM_Point [0..3]" is converted to:

An attribute "<<voidable>> event : Event [1..*]" is converted to:

A navigable association role "role : Feature [1..*]" is converted to:

Note that no OwnershipAttributeGroup is added for attributes as attributes are equivalent to compositions.

For properties with a tagged value 'gmlListProperty' set to 'true' and with a simple type as value, maxOccurs is suppressed and a list type is created.

Examples:

An attribute "string : CharacterString [1..*]" is converted to:

An attribute "integer : Integer [0..3]" is converted to:

If this property is also marked for conversion to an attribute ('xsdAsAttribut' set to 'true' and rule 'rule-xsd-prop-xsdAsAttribute' is active), the result is:

(since v2.4.0)

Applies simple byReference encoding of properties with a feature type as value type. In other words, such properties are encoded as elements with type gml:ReferenceType.

If an attribute has an initial value, it is converted to a default value in XML Schema. If the attribute carries the constraint "{frozen}", too, the initial value is converted to a fixed element value in XML Schema.

CharacterString valued properties that carry the tagged values 'length', 'size' or 'pattern' are converted to anonymous types with restricting facets according to the tagged values.

(since v2.9.0)

If a property has stereotype <<propertyMetadata>>, then the XML element that represents this property will have an additional, optional XML attribute "metadata" of type xs:anyURI. The XML attribute can be used to reference a metadata object that applies to the property value.

(since v2.4.0)

Applies simple byReference encoding of properties with metadata as value type (determined by tagged value isMetadata on the property, and map entries in the ShapeChange configuration). In other words, such properties are encoded as elements with type gml:ReferenceType.

Converts properties with stereotype <<voidable>> - or alternatively with a tagged value nillable set to 'true' - to property elements that are nillable.

In GML this implies that xsi:nil is set to 'true' and a nilReason attribute is added to the content model of the property element.

In ISO/TS 19139, the property element may have no element content and the content model has a gco:nilReason attribute.

Extension: nillable, nilReasonAllowed and implementedByNilReason

If an attribute has a tagged value "nillable" with value "true", the property element will be defined with its nillable attribute set to "true".

If a type has a tagged value "nilReasonAllowed" with value "true", all property types for this property will be defined with an optional nilReason attribute.

If a property of the conceptual model is implemented by the nilReason concept of GML, the tagged value "gmlImplementedByNilReason" is set.

Note that there is considerable overlap with rule-xsd-prop-nillable. This should be cleaned up in a future version.

(since v2.9.0)

This rule applies to a property that 1) is nillable (as defined by rule-xsd-prop-nillable) and 2) has a defined void reason type, either via tagged value voidReasonType on the property itself, or globally via the target parameter defaultVoidReasonType.

The void reason type is an enumeration, with each enum identifying an allowed nil reason. The enumeration is identified by its name: the simple classifier name, if the enumeration belongs to the schema that is being processed by the XmlSchema target, or the full package-qualified name, starting with the package of the schema to which the enumeration belongs (e.g. "Some Application Schema::Some Subpackage::Another Subpackage::VoidReason").

If the conditions are met (property is nillable and has a defined void reason type), then a Schematron assertion is generated to ensure the following: If an XML element representing the property has a nilReason XML attribute, then the value of that attribute must be equal to the name of one of the enums defined by the void reason type. In other words, the Schematron assertion checks that only the reasons defined by the void reason type are used within the nilReason XML attribute.

For associations with qualifiers, the qualifiers are converted to XML attributes of the reverse property element. The multiplicity is set to minOccurs="0" and maxOccurs="unbounded". Qualifiers with types that map to simple types use the type directly. Qualifiers with types that map to types with identity use xs:anyUri. In all other cases xs:string will be used as a fallback.

Examples:

An association role "role1" (multiplicity "1", by-reference encoding) with a single qualifier "q : Integer" in the reverse role is converted to:

An association role "role2" (multiplicity "0..1", inline encoding) with the qualifiers "q1 : CharacterString; q2: SomeObject" in the reverse role is converted to (Parcel is a feature type):

(since v2.4.0)

For a property with a code list as value type, and the code list has non-empty tagged value codeList (or vocabulary), add an sc:targetCodeListURI appinfo element with the value of the according tag.

(since v2.9.0)

If schematron generation is enabled (via rule-xsd-pkg-schematron), then schematron assertions are created to ensure that if an XML instance contains elements representing a nillable property (as defined by rule-xsd-prop-nillable), then either there is only a single such element that is nil (XML attribute xsi:nil is true), has a nilReason XML attribute, and no value - or all of these elements are not nil, do not have nilReason attributes, and have values.

If the tagged value 'xsdAsAttribute' is set to 'true' on a property, the property has a maximum multiplicity of 1 and the value of the property is simple, the property is converted to an XML attribute instead of an XML element.