LEVEL 3 USER
DATEX II models can be extended using extensions. The following conditions must be kept in mind:
The following rules apply to level B extensions:
The following rules are applicable to UML usage:
Below is an example of an extension called MyLevelBextension.
To new classes it’s allowed to
Below is an example of a valid extension of a class extended by a new attribute(numberOfParticipants) and a relation to a new class(Address).
When building new DATEX II models that have at least some re-use of existing DATEX II model elements, there are choices about which kinds of modelling constructs to use, and where to place them. This section offers a guide. It is designed to encourage future re-use while keeping it cost-effective, and is applicable to any DATEX II modelling, from specific project work to DATEX II TMG members creating new versions of the standardised DATEX II models.
Namespaces and packages
A DATEX II namespace can be considered as a unit of reuse of a model. There are a growing number of namespaces in DATEX II models; each specific application does not require every namespace, but rather a selected subset. Namespaces provide modularity in DATEX II. Model element names must be unique in a DATEX II namespace.
A DATEX II package is only a grouping construct that makes the model easier to read.
New publication classes
When modelling new kinds of DATEX II publications, the modeller has a choice whether to extend PayloadPublication directly, or extend its concrete subclass GenericPublication. Abstract classes cannot be the subject of DATEX II Level B extension, so the abstract PayloadPublication should be extended by regular UML specialisation, whereas the GenericPublication enables Level B extension. Using GenericPublication with Level B extension allows a very limited amount of extra interoperability – it allows receivers of the new publication to perform validation on the data content even if they do not know the schema for the new publication, but that validation only verifies that the data is a valid GenericPublication object, which is not much of an advantage. Unless there is a desire to support this limited feature (or some other limited generic processing of a GenericPublication) it is recommended to specialise PayloadPublication directly.
Such a direct specialisation means that by DATEX II methodology rules this model is considered a “Level C extension.” A Level C extension should not be considered inferior to a level B extension, it’s just that a Level C extension does not aim to support instances of the extension being substituted for instances of the core DATEX II model.
Another valid but unusual option is to extend another concrete publication class, giving a variant with extra information in new attributes or associations of the new publication. There is benefit in using Level B extension in that case, to allow instances of the new publication to be processed by a wider set of implementations.
Extending existing classes
Say within the details of a publication model a modeller wants to reuse an existing class in an existing namespace but with added features (great!).
If a modeller is already creating a Level B extension, because of a need for instances of the extension to be valid instances of the core DATEX II model, then regular specialisation relationships across the boundary between the core DATEX II model and the extension are prohibited by DATEX II methodology rules. All specialisation relationships across this boundary must be << D2LevelBExtension>>.
If a modeller is trying to create an entirely new kind of publication in a new namespace, the best approach depends on whether the extended class is very specific to a new purpose or is considered just as widely useful as the original class.
Note
However, if the extended class is specific where the parent class is general, that may be a hint to consider whether a composition relationship may be be more appropriate than a generalisation/specialisation relationship in the first place. Valid cases of regular UML specialisation across a namespace boundary include new publications that specialise PayloadPublication.
New level B extended classes should be placed under the Extension package of DATEX II. (If this new class is shared with the community, it might be selected for promotion as an “approved extension” of DATEX II and its features merged into the original class in the next major revision of DATEX II.)
New classes under the Extension package should be given a namespace whose name should be chosen carefully. A name like “SituationExtension”, although it has the advantage of signalling an intention to extend the Situation namespace, has the disadvantage that multiple projects could choose the same name, and then the models cannot easily be used together in the same implementation. Furthermore the DATEX II TMG may use that kind of name in minor releases of the DATEX II model, to signal that these concepts will be promoted to the original class in the next major release, so for other purposes this kind of namespace name should be avoided.
New model elements with wider re-use potential
When creating a new kind of publication in a new namespace, there may be new classes, enumerations or datatypes created that are considered more generally useful for a wider range of applications.
The following rules are implemented by the tool and defined by the methodology document. They are described here for those that are interested.
<xs:complexType name="_ExtensionsType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
This means that every class can be extended with anything and, if extended, it’s known where the extension can be found.
<xsd:complexType name="_MyClassExtensionsType">
<xsd:sequence>
<xsd:element name = "myClass" type ="Namespace:MyClass" minOccurs="0">
<xs:any namespace="##other" processContents="lax" minOccurs="0 maxOccurs="unbounded"/>
</xsd:any>
</xsd:sequence>
</xsd:complexType>
Note
_[ClassName]ExtensionsType will be used as type on [Classname]Extension element instead of _ExtensionsType.
<xs:simpleType name="_"EnumerationNameFromUMLModel"ExtensionType">
<xs:restriction base="xs:string">
<xs:enumeration value=NameOfLiteralFromExtension />
...
</xs:restriction>
</xs:simpleType>
<xs:complexType name="_"EnumerationNameFromUMLModel>
<xs:simpleContent>
<xs:extension base=Namespace:EnumerationNameFromUMLModel>
<xs:attribute name="_extendedValue" type="xs:string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
Note
The solution allows a Level A instance to validate against any Level b extended model/schema as long as the modelBaseVersion is the same. An extended Level B instance can be validated against any Level A schema as long as the modelBaseVersion is the same.
There are two known limitations.
The next image gives an overview of situation where successful validation is possible.
V[X] means Version of the interface where 1 and 2 is the version number. A means a Level A model / schema / interface B1, B2 means a Level B model / schema / interface. But they are different extensions. The arrows show between which interfaces successful validation can be performed. If there is no arrow between two interfaces then successful validation cannot be done
The following rules apply to level C extensions:
The following rules are applicable to UML usage:
To make sure the namespace name and the schema name is not the same for Level C and Level A and B the beginning of the names are read from the configuration file. The schema name will begin with LevelC and the namespace will begin with http://levelC/schema. These two values can be changed in the configuration file.
Importing and exporting extensions are preferable done with XMI. In EA you highlight the package in the project Tree and choose import / export and the either “import package from XMI file” or “export package from XMI file”.
Import dialog looks like this
Select the file and press Import. | The export dialog looks like this.
Choose file name and make sure the selections and versions of XMI is as above.Press Export.
Extensions in XMI format can easily be shared, because it’s just a file. If you have an extension that is used by more then one, please share this extension on the website www.datex2.eu. There is a extensions directory where you can upload your extension (XMI, UML model, XSD and documentation). Known extensions can be candidates for inclusion in future versions of DATEX.