In HeaderInformation Class urgency attribute refers to "information deliver " not to information about a Situation.

Definition: "This indicates the urgency with which a message recipient or Client should distribute the enclosed information.  Urgency particularly relates to functions within RDS-TMC applications.  "

The 'new' Enterprise Architect versions from 8.0 up to the current version 9.31 have a different behaviour in exporting Qualifiers to XMI than version 7.5.

The new behaviour is not yet implemented in the DATEX Tool, therefore DATEX profiles with qualifiers will be incorrect, when using a new version of Enterprise Architect.

Jonas Jäderberg is informed about technical details, there's also a bug report to Sparx Systems pending.

Solutions:

When using the tagged value "order" with some characters (instead of a non-negative integer), an unspecified XMI-error will occur when using the Tool (see attachement).
Of course the model does not allow characters, but in this case an explicit warning would be nicer than this unspecified error.

Consider the example to define a PredifinedItenerary-Publiction containing a huge amount of Points. In the current DATEX-model, every single Point would be a "PredifinedLocation", i.e. every point is referenced with version and id.
Obviously this is not what you want, and the maintenance of those refences might even result in performance problems.
The same problem exists for NonOrderedLocationGroup.

I can think of two solutions:

by definition feedType is related to filter facilities used in some implementation where different URLs deliver different types of content based on filters

these attributes should be better related to Exchange package

The following can happen:
A client is developed against a level B extension "X". It connects to a server that has been developed against another level B extension "Y". In the case where extensions X and Y both contain a level B extensions class (i.e. a class with a tagged value named "extension" and set to "levelb") with the same name, the client will misinterprete the extension content with unpredictible result.

Proposal:

Today the tool take the version from the assembly (2.0.XX) and uses the major and minor version as part of the namespace and schema name.
Now, we change to version 2.1 and we don't want to change the namespace but the tool should have version 2.1.
In future, the tool version could be removed from the namespce.

Possiby the simpliest solution now is to introduce a configuration parameter in the config file,

The two tragged values "extensionName" and "extensionVersion" are mapped to XML attributes for instances that are created from an extended schema. They are defined in that schema as XML attributes of the D2LogicalModel class.

The claim for level B extensions is that all valid instances are also valid against the "big" schema (i.e. as a reference).

The full schema does NOT contain the definition of the "extensionName" and "extensionVersion" XML attributes.

Extensions can be uploaded to the datex2.eu website and proposed for standardisation as well as exposed to the wider user community. They have a a name and a lifecycle, which is captured in the PIM - tagged values extensionName and extensionVersion in class D2LogicalModel - and also can be found in the schema as XML attributes on the complex type generated from that class.

The DATEX II namespace for the 2.x generation of DATEX II contains the major release number ("2") PLUS the full (i.e. major and minor) version number of the tool ("2_1"). This does not make any sense and should be removed from the next version on. Instead fo this, an appropriate XML attribute (e.h. "schemaCreationToolVersion") should be introduced to indicate the real full version of the tool without hampring with the namespace.