- 1 Overview
- 1.1 Stereotypes
- 1.2 Tagged Values
- 1.3 OCL Constraints
- 1.4 Requirements of the XML Schema output target
- 1.5 Additional Requirements
To be a valid input into the mapping the application schema should conform to ISO 19109:2005, and GML 3.2 (ISO 19136) Annex E, GML 3.3 and/or ISO/TS 19139.
In addition, extensions to these latter specifications are supported, too, but must be activated in extended encoding rules; see here for details.
Well-known stereotypes for the purposes of ShapeChange are those defined in the UML specification, and in the ISO 19100-series of specifications, specifically ISO/TS 19103:2005, ISO 19109:2005 and GML 3.2/ISO 19136:2007.
Stereotypes are not case-sensitive. The stereotypes used in the ISO 19100 standards usually start with a upper case letter, but today the common practice is to start with a lower case letter and avoid whitespace.
Standard aliases listed for a stereotype can be used, too. Aliases can be configured.
All stereotypes not listed below are ignored.
In UML 1, only one stereotype per model element are supported. UML 2 introduced the capability of model elements to carry more than one stereotype. This capability is not yet supported by ShapeChange. If a model element has more than one stereotype, an arbitrary stereotype from the list is used.
Stereotypes of packages
|no stereotype||<<bundle>>,<<leaf>>||A <<leaf>> package is a package that is not an application schema and contains no packages. [ISO/TS 19103]. A <<bundle>> package is a package that is not an application schema and contains other packages [GSIP]. For encoding purposes, these stereotypes are not relevant and thus specified as an aliases to no stereotype.|
|<<Application Schema>>||<<applicationSchema>>,<<schema>>,<<requirementsClass>>||An application schema according to ISO 19109 [ISO 19109]. The alias <<schema>> has been introduced for packages that should be treated like application schemas, but do not contain feature types.|
Stereotypes of classes
|no stereotype||<<abstract>>||A standard class, instances are plain objects with identify. The stereotype <<abstract>> is used by some models, but should be avoided. If a class is abstract, this must be indicated using the UML flag for abstractness, not the stereotype. If the stereotype is provided, it is ignored.|
|<<DataType>>||<<request>>, <<response>>||A structured data type without identity [ISO/TS 19103]. The <<request>> and <<response>> stereotype were originally used in AFIS-ALKIS-ATKIS to distinguish data types for use in messages of services. For all encoding purposes these are treated as data types and are configured as aliases.|
|<<FeatureType>>||<<feature>>||A feature type [ISO 19136]. Some schemas have used <<Feature>>, so this has been added as an alias.|
|<<CodeList>>||<<conceptScheme>>, <<vocabulary>>||A code list. <<conceptScheme>> and <<vocabulary>> have been used to identify collections of enumerated values that may also have relationships like 'narrower'; for encoding purposes these are treated like code lists.|
|<<Union>>||A structured data type without identity where exactly one of the properties of the type is present in any instance [ISO/TS 19103].|
|<<BasicType>>||A basic type with a simple representation on most platforms. Usually it is a restriction of CharacterString or Number.|
|<<Interface>>||For the purpose of transfer application schemas, this is the same as <<Type>>, see below.|
|<<Type>>||<<interface>>||A type that is not directly instantiable, but is used as an abstract collection of operation, attribute and relation signatures. This stereotype should usually not be used in application schemas as these are on a different conceptual level than classes with the <<type>> stereotype. In the encoding these will usually be treated as if no stereotype has been set. <<Type>> has been deprecated in UML 2 and <<Interface>> should be used instead.|
|<<FachId>>||OKSTRA feature types where instances may be referenced through symbolic links. See the OKSTRA documentation (in German)."|
|<<Schluesseltabelle>>||OKSTRA Schlüsseltabellen. See the OKSTRA documentation (in German)."|
|<<ADEElement>>||Feature type in an CityGML Application Domain Extension (ADE) that contains only properties that are generic application extensions.|
|<<featureConcept>>||A feature concept in a feature concept dictionary (see ISO 19126). If a feature type classifier has a dependency to a feature concept classifier of the same name, ShapeChange will use the documentation of the concept as the documentation of the feature type, if the documentation of the feature type classifier is empty.|
|<<attributeConcept>>||An attribute concept in a feature concept dictionary (see ISO 19126). If a feature type classifier has a dependency to an attribute concept classifier and a property of the same name, ShapeChange will use the documentation of the concept as the documentation of the property, if the documentation of the property is empty.|
|<<valueConcept>>||A nominal value concept in a feature concept dictionary (see ISO 19126). If an enumeration has a dependency to an value concept classifier and an enumerant of the same name, ShapeChange will use the documentation of the concept as the documentation of the enumerant, if the documentation of the enumerant is empty.|
|<<AIXMExtension>>||Type defined in an AIXM extension schema. It extends a specific feature or object type or all feature types, usually from the core AIXM schema.|
Stereotypes of properties
|no stereotype||<<property>>||The standard case for properties.|
|<<version>>||If in an application schema an association role ends at a spatial object type, this stereotype denotes that the value of the property is meant to be a specific version of the spatial object, not the spatial object in general. [INSPIRE]|
|<<voidable>>||If a characteristic of an object is not present, but may be present or applicable in the real world, this can be reflected using this stereotype. This is a shorthand notation for a union type of the normal value range with a void/nil value plus an optional reason for the void/nil value. [INSPIRE]|
Stereotypes of dependencies
|no stereotype||For package dependencies without a stereotype, <<import>> is implied (source: ISO 19136:2007, section E.22.214.171.124).|
|<<import>>||The model elements of the supplier package are imported.|
NOTE: ShapeChange stores package dependencies without stereotypes. In other words, stereotypes on package dependencies are ignored (thus, it does not matter if such a dependency has the stereotype <<import>>, <<include>>, or any other stereotype). ShapeChange determines if an application schema has a dependency on a different application schema by examining the target namespaces of both packages; if they are different, the two packages belong to different application schema – otherwise, they belong to the same schema.
Stereotypes of generalizations
|no stereotype||The standard case.|
|<<disjoint>>||The constraint added to a set of generalization relationships indicates that an instance of the parent may be an instance of one and only one of the children within the set. This is implicitly assumed to be the case.|
NOTE: ShapeChange ignores stereotypes on generalizations.
Tagged values are used to represent additional information in the UML model that are either specific to an encoding or which require a name-value-pair.
To document: “xsdDerivation”, “gmlAsGroup”, “length”, “base”, “rangeMinimum”, “rangeMaximum”, “default”, “nilReasonAllowed”, “gmlImplementedByNilReason”, “primaryCode”, “secondaryCode”, “oclExpressions”, “schPatterns”, “unitMeasure”, “voidable”, “description”, “infoURL”, “gmlAsCharacterString”, “gmlMixin”, “nillable”, “suppress”, “codeList”, “codeListValuePattern”, “codeListRepresentation”, “uomResourceURI”, “uomResourceValuePattern”, “uomResourceRepresentation”, “physicalQuantity”, “recommendedMeasure”, “noncomparableMeasure”
Tagged values of all model elements
|documentation||any stereotype||The documentation for the model element. [UML]|
|xsdEncodingRule||any stereotype||XML Schema encoding rule to apply. Default is iso19136_2007.|
|alias||any stereotype||An alias of the name of the model element, usually for presentation to a human.|
Tagged values of packages
|targetNamespace||<<applicationSchema>>||The target XML namespace of the application schema [ISO 19136]|
|xmlns||<<applicationSchema>>||Namespace prefix to be used as short form of the target namespace [ISO 19136]|
|version||<<applicationSchema>>||Current version of the application schema [ISO 19136]|
|xsdDocument||<<applicationSchema>>, no stereotype||Name of an XML Schema document to create representing the content of the package [ISO 19136]|
|gmlProfileSchema||<<applicationSchema>>||URL of the schema location of a GML profile (where applicable) [ISO 19136]|
Tagged values of classes
|noPropertyType||no stereotype,<<featureType>>,<<type>>,<dataType>>,<<union>>||Suppress creation of a standard property type that supports inline or by-reference encoding [ISO 19136]. For data types only inline encoding is supported. Should usually be set to false.|
|byValuePropertyType||no stereotype,<<featureType>>,<<type>>||Create a property type that requires that the instance is encoded inline [ISO 19136]. Should usually be set to false.|
|isCollection||no stereotype,<<featureType>>,<<type>>||Identifies the type as a collection [ISO 19136].|
|asDictionary||<<codeList>>||If the value is 'false' the code list will be encoded with the pre-defined enumerants as values in the schema, if 'true' all enumerants will only be maintained in external dictionaries. The default depends on the encoding rule used [ISO 19136, GML 3.3].|
|defaultCodeSpace||<<codeList>>||The URI of the default dictionary that contains code list [ISO 19136].|
|codeList||<<codeList>>||The URI of the code list dictionary. This is similar to 'defaultCodeSpace', but is less GML-specific. Alias to 'vocabulary'.|
|resourceURI||<<codeList>>||Alias to 'vocabulary'.|
|xmlSchemaType||<<type>>||If the type has a canonical XML Schema encoding the XML Schema typename corresponding to the data type shall be given as the value [ISO 19136].|
|gmlMixin||no stereotype, <<type>>, <<featureType>>||Identifies the type as a mixin type that will not be encoded as a separate element/type in the XML encoding, but properties will be copied to subtypes. This is a ShapeChange extension.|
|extensibility||<<codeList>>||This refers to extensions by a third party, not to extensions by the owner of the vocabulary; the owner will always be able to revise the vocabulary. I.e., if the value is 'none', the referenced vocabulary may not be extended by third parties; if the value is 'narrower', the vocabulary may be extended by narrower terms that have an existing term as a parent; if the value is 'any', the vocabulary may be extended by additional terms on any level. This value must be 'any', empty or missing, if the value 'vocabulary' is empty or missing; in this case any vocabulary may be used. [INSPIRE]|
|vocabulary||<<codeList>>||URI of the vocabulary/code list in a registry. [INSPIRE]|
Tagged values of properties
|sequenceNumber||any stereotype||Unique integer value for properties of the type used to sort properties [ISO 19136].|
|inlineOrByReference||any stereotype||Controls whether property values may be encoded inline or by reference. Valid values are 'inline', 'byReference' and 'inlineOrByReference'. Default is 'inlineOrByReference'. [ISO 19136]|
|isMetadata||any stereotype||Indicates whether the property is considered metadata about the instance – and not information about the phenomenon in the real world [ISO 19136]. 'true' or 'false', the default is 'false'.|
|obligation||any stereotype||The value type of the property must be a <<codeList>>. The use of the referenced code list may be made legally required in the implementing rule ('implementingRule') or only in the technical guidance ('technicalGuidance'). This value must be empty or missing, if the value 'vocabulary' in the value type is empty or missing. [INSPIRE]|
|xsdAsAttribute||any stereotype||If set to true, the property has a maximum multiplicity of 1 and the value of the property is simple, a value of 'true' converts the property to an XML attribute instead of an XML element.|
In an extension to the standard encoding rules, ShapeChange supports also parsing of OCL constraints in the application schema (not for XMI 1.0 models, as these have no standard mechanism for representing constraints). The supported set of expressions is documented here.
If the UML tool does not support OCL constraints directly, constraints may also be represented in a tagged value “oclExpressions”.
Requirements of the XML Schema output target
All model elements in application schema packages must meet the requirements in this section, if the XML Schema target is used.
Requirements for all model elements
None at the moment
Requirements for packages
|req-xsd-pkg-xsdDocument-unique||All tagged values xsdDocument in a UML model must be unique.|
Requirements for classes
|req-xsd-cls-ncname||Each class name must be a NCName.|
|req-xsd-cls-name-unique||All class names within the same application schema must be unique.|
|req-xsd-cls-mixin-supertypes||Mixin classes must have no instantiable supertypes.|
|req-xsd-cls-mixin-supertypes-overrule||Overrules req-xsd-cls-mixin-supertypes and allows that mixin classes may have supertypes that are not mixin.|
Requirements for properties
|req-xsd-prop-value-type-exists||The value type shall either be a predefined type or a class defined in the UML model.|
|req-xsd-prop-data-type||If the value type is data type, the property must be an attribute or a composition.|
|req-xsd-prop-ncname||The property name must be a NCName.|
GML requires that a tagged value “sequenceNumber” shall be specified for every attribute. The value shall be an integer and be unique for all attributes and association ends of a class. As the sequenceNumber values are used to organize the properties of a class, this cannot be tested in the validation step, but errors are reported during the initial processing of the model.
ShapeChange supports a more flexible approach for sequenceNumber values than the GML standard:
- the value may omitted in which case ShapeChange determines its own order;
- the value may be a structured integer, e.g. values like “4.2.3”.
Multiplicities and visibility are also evaluated during the initial model read process and cannot be validated at a later stage. Any errors and warnings are reported while reading the model.
Requirements for associations
Navigability is evaluated during the initial model read process and cannot be validated at a later stage. Any errors and warnings are reported while reading the model.
These requirements may be added in encoding rules.
Requirements for all model elements
|req-all-all-documentation||Name and definition separators ('– Name –' and '– Definition –') must be included in the documentation (Source: INSPIRE).|
Requirements for packages
|req-xsd-pkg-targetNamespace||The tagged value targetNamespace must be set, if the package is an application schema. If the tagged value is missing a default value will be used.|
|req-xsd-pkg-xmlns||The tagged value xmlns must be set, if the package is an application schema.|
|rec-xsd-pkg-version||The tagged value version should be set, if if the package is an application schema. If the tagged value is missing a default value will be used.|
|req-xsd-pkg-xsdDocument||The tagged value xsdDocument must be set, if the package is an application schema. If the tagged value is missing a name will still be constructed from the package name.|
|req-xsd-pkg-dependencies||All dependencies must be between schema packages (i.e., packages with a targetNamespace).|
|The tagged values targetNamespace and xmlns may only be set, if the package is an application schema.|
Requirements for classes
|req-xsd-cls-generalization-consistent||A generalization relationship may be specified only between two classes that are either: both feature types, both object types, or both data types.|
|req-xsd-cls-codelist-asDictionary-true||For code lists the tagged value asDictionary must be 'true' (Source: INSPIRE).|
|req-xsd-cls-codelist-extensibility-values||For code lists the tagged value extensibility must be empty, narrower, any (Source: INSPIRE).|
|req-xsd-cls-codelist-extensibility-vocabulary||For code lists the tagged value extensibility!=any implies that a vocabulary is provided (Source: INSPIRE).|
|req-xsd-cls-codelist-no-supertypes||Code lists must have no supertypes (Source: INSPIRE?).|
|req-xsd-cls-datatype-noPropertyType||For data types the tagged value noPropertyType must be 'false' (Source: INSPIRE).|
|req-xsd-cls-enum-no-supertypes||Enumerations must have no supertypes (Source: INSPIRE).|
|req-xsd-cls-objecttype-byValuePropertyType||For types with identity the tagged value byValuePropertyType must be 'false' (Source: INSPIRE).|
|req-xsd-cls-objecttype-noPropertyType||For types with identity the tagged value noPropertyType must be 'false' (Source: INSPIRE).|
|req-xsd-cls-suppress-no-properties||If the tagged value suppress is 'true' the class must have no properties (Source: Metadata profiling).|
|req-xsd-cls-suppress-subtype||If the tagged value suppress is 'true' the class must have no unsuppressed subtype (Source: Metadata profiling).|
|req-xsd-cls-suppress-supertype||If the tagged value suppress is 'true' the class must have an instantiable supertype (Source: Metadata profiling).|
Requirements for properties
|req-xsd-prop-codelist-obligation||For code lists, a tagged value obligation must exist (Source: INSPIRE).|
Requirements for associations
None at the moment