The fulle (i.e. non-extended, non-profiled) DATEX II schema is made availabke to users via the DATEX II website for download, but in an inconvwenient and unconventional way. The schema can be dwonloaded in two versions (w/o comments) in a ZIP archive. This does not allow applications to refer to the schema in the usual way via an URL. Hence, the sample messages refer to the schema via a relative file path (..\..\Schema\DATEXIISchema_2_0RC2_2_0.xsd).

If you make a selection (I checked only the MeasuredDataPublication and the MeasurementSiteTablePublication by unchecking the others) and then change to another tab (Configuration or Log), the selection has changed. In my case e.g. everything under BasicData now is unchecked.
I guess it might be a problem if there are only optional elements under a mandatory element.

Btw. it would be very helpful if loading times could be faster. Turn around times (changing something in the model due to logs of the tool) are really annoying.

It is awkward that the mapping of UML qualifiers generates two redundant, nested XML elements of the same name.
Example:
                    <measurementSpecificCharacteristics index="0">
                        <measurementSpecificCharacteristics>

The tool maps qualifiers to XML attributes with the name of the qualifier, e.g.:
  <xs:complexType name="_VmsPictogramDisplayAreaIndexPictogramDisplayAreaSettings">
    <xs:sequence>
      <xs:element name="pictogramDisplayAreaSettings" type="D2LogicalModel:PictogramDisplayAreaSettings" minOccurs="1" maxOccurs="1" />
    </xs:sequence>

The methodology should be based un UML 2.x instead of the outdated UML 1.4. This would also imply that all tagged values are expressed as belonging to stereotypes. Hence, the "unstereotyped UML classes" (i.e. the components in DATEX II terminology) shoudl also have a stereotype (e.g. <<component>>). In this process, the UML profile provided with the Enterprise Architect model should also be revised and improved.

The current WS exchange specification is only a rudimentary fragment of what would be needed to properly set up DATEX II exchange connections via WS. Just some examples:
- the client should be able to query configuration information (e.g. which publications are provided, are extension used, etc.)
- there should be support for catalogues and filtered / partial subscription
- a detailed specification plus WSDL of the subscription interface is missing

Some user have complained about the monolitic, large DATEX II schema. They suggest to consider a more modular approach, where the schema is split into different schemas that import/inlcude each other in a suitable way. Whether this applies just for the distribution of the schema of various files or whether this implies splitting up into several namespaces is to be considered. The impact on sub-schema generation will also have to be looked at.

The eight Enumeration types defined in the ExchangeEnumerations package are not modelled properly. According to the methodology, types must be either classes with a <<datatype>> stereotype or UML Enumerations. The eight classes are used as types but are neither of those. CompressionMethodEnum doesn't seem to be used at all. Concequently, the seven attributes that denote the seven used UML classes of that package as their type are vialoating the methodology: "UML Attributes shall have an assigned "type" element.

I can not see how it is possible to exchange DATEX II Level C messages using the current exchange WSDLs. The methodology / tool prescribe that Level C model will have a different namespace, which is provided by the modeller of the extension. On the other hand, the two WSDLs are hard-coded to import the DATEX II schema into the Level A/B namespace. I must admit I am not a WSDL expert, but I cannot see how this should work?

The current top level structure - which is normative! - provides only one entry point (i.e. root element in the schema) into the DATEX II data model, called d2LogicalModel, an instance of the class D2LogicalModel.