The "VehcileTypeEnum" enumeration type for vehicle classifications seems to be inconsistent.
We may have cars and cars with trailer, in the same way we may have lorries and lorries with trailers.
To make the first distinction I would use unique values: "car" and "carWithTrailer".

I've had many complaints from users about excessive enumerations from which only very few literals were actually used by a service without being able to restrict the enumeration in the subschema generation process. The subschema significantly looses expressiveness without this feature and creates potential interoperability problems. I suggest that the tool alows deselecting unused literals in the schema generation process.

The current naming convention seems overly restrictive for enumeration literals. I n a modelling effort related to transport of dangerous goods, I encountered a lot of fixed lists that are actually sequences of numerical codes (e.g.: {"1", "2", "3", "4.1", "4.2}). The canonical encoding would be an enumeration with just these codes as literals. This is not allowed currently. I can't see why naming conventions for enumeration literals have to be that restrictive. In XML they are mapped to XML element content, which is fine.

In the Exchange package there are attributes that reference catalogues and filters by using the VersionedReference <dataytype>. But currently the model does not contain the modelling of catalogues and filters and hence the Schema Tool generates warnings to indicate that these references do not exist.

Until catalogues and filters are specified in the model these references should be changed to be String <datatype>, the agument being that currently, if used, catalogues and filters need to be defined off-line and Strings used to reference them.

As part of the Data Quality work modelling of fault information was modified.
 
- Fault was made a reusable class containing generic fault information
- The intention was that each equipment reporting a fault status would specialise this class and add own specific fault information
- Therefore the fault attribute was removed from BasicData

The new version tagged value should be mapped to the version attribute of the root of the schema.

xmlns:xs="http://www.w3.org/2001/XMLSchema" version=”2.0”

The submitted Editorial changes to the CEN drafts leads to the following changes
1.       modelBaseVersion tagged value should have the value 2 in the model
2.       A new tagged value version in the model

On extensions
e.g.
  <xs:complexType name="_TrafficSpeedExtensionType">
    <xs:sequence>
      <xs:element name="TrafficSpeedExtended" type="D2LogicalModel:TrafficSpeedExtended" minOccurs="0" />
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" />
    </xs:sequence>
  </xs:complexType>

I suggest to add the attribute 'train' to the VehicleType-enumeration (think about railraod crossings, for example).

When releasing new versions of the tool we need to have a good practice for versioning of released versions of the tool. A solution is to use build numbers. Example next update of the tool could  have the version 2.0 Build: 3140.

We also need to make the build number visible in the about dialog of the tool. Thisis important to hvae when users report bugs.

Included in build 3902 released 2010-09-07