All components for data types are derived from the superclass "DataValue". But the component "DataValue" can't be found in the tree (of the DATEX-Tool), as there's nowhere a direct access to this class.
Newertheless it's generated properly in the .xsd; but the idea is to deselect some of the optional attributes in it, which is not possible in my opinion (there might be even some more situations like this).

The Enumaration 'MeasuredOrDerivedDataTypeEnum' is used in a mandatory way in 'MeasurementSpecificCharacteristics', but does not offer some literal like 'other'.

Such a literal might be necessary in case of a Level B Extension, if someone wants to expand or replace this Enumaration.

--> Add literal 'other' to MeasuredOrDerivedDataTypeEnum and have a look through the model, if there are more situations like this (maybe even create a rule for that).

 from Cen review  from SE

VmsFault and VmsUnitFault is missing in the dictionary.
 
They are not defined in earlier documents either. Add VmsFault and VmsUnitFault to the data dictionary.
 
Possibly also Fault should be added since it is the first time it is used in the DATEX specifications.

to be corrected 

CZ Report to CEN enquiry

- There are attributes named “maxFontHeight”, “maxFontSpacing”, “maxFontWidth”, “maxNumberOfCharacters”, “minFontHeight”, “minFontSpacing” and “minFontWidth”.  These attributes are part of class  VmsTextDisplayCharacteristics”. While these attributes could hold interesting information, it is usable only in case of non-proportional fonts. But there is no information about proportionality of font, which could be also interesting.

SE raised the following  Comment: 

GB 8.2j
ed

There would be a potential benefit for the XML mapping
information to be moved out of clause 8 which is
otherwise platform-independent. This mapping
information would be better in Annex D.

Move XML mapping description to Annex D

GB
8.2c
ed

The base model version is "2". This is presumably
because the DATEX II model had reached version 2.0 at
the point of CEN adoption, and not because 2 refers to
the "II" in DATEX II. However there is a small risk of
confusion over this.

Add a note to distinguish the concepts at this
point.

GB
8.2a
te

The name "D2LogicalModel" breaks a rule of good
practice for modelling: that the name of a class should
describe an instance of the class, and in general the
model should be named to represent the thing being
modelled. This model is the D2LogicalModel, it does not
represent the D2LogicalModel. There may be a counterview
that the data represents an abstract model of traffic
and travel environment and so the subject matter is itself
still a model; however this view overloads the word

GB
7.2w
te

This requires a definition for an association rather than
the named association end. While there is some
justification for this, we prefer the practice of adding a
definition for the named associated end; the latter is
better aligned with programming language
implementations, where the defined association end (not
the association) will become a property.

Require definition for association end rather than
association.

GB

7.2

ed

Usage of the terms "source" and "target" imply a meaning
that is beyond that defined in UML v1.4 where the terms
are simply relative to the end being discussed at the time.
Some parts of clause 7.2 seem to imply that an
association always has a fixed target end and a fixed
source end. This may be how UML is implemented in one
tool but conflicts with usage in the standard.

Clarify usage of "source" and "target".