Different users (e.g. actual operators or other client software such tactical decision aids) may require / prefer different categorization representations. However, the Entity data model forces a choice of selecting a single option on the publisher.
Consequently, the logic for how to convert between different representations may become spread around different components of a system. A better system architecture is to have knowledge and functionality with the producer of the data. That component can best judge the equivalence of different representations in the context of their own data.

To support tactical decision aid functionality (see www.omg.org/spec/TDAI) and track correlators in particular, TEX entities need to contain uncertainty information as a first-class property; e.g. covariance matrices.

The Shaped Entity class has a table of connection description but no table for its attributes

The speed, direction of movement and climb angle attributes of shaped entities are generally unknown and do not make sense if that entity is a bearing type. However, in the model they are mandatory attributes so have to be supplied.

The attribute use clashes with common software language syntax and is also ill-defined.

The PSM Mapping for DDS repeats the base attributes for classes such as EntityType in each of its specializations. Particularly as EntityType has an extensive inheritance tree this leads to inefficient code in the users of the interface.

There is no TACSIT or TEX root namespace for the IDL modules. This means that there is potential to clash with applications code as well as causing confusion.

SI is an enum literal attribute in the DistanceUnit and SpeedUnit enumeration classes. When mapped to C++ and other languages (e.g. through the IDL to DDS mapping for the TEX DDS PSM) this is a namespace clash and a compilation/build issue.

The DDS IDL for the schema of extended data is
"ExtendedData__id_type _id;"
This is missing the name, missing description and is an inappropriate underlying type - int. It would be natural to refer to a schema through a schema prefix.

The description for the arrow class is "An entity represented as a polyline."

AISCategorizationData cargoCategory is defined as "The IMO categorization of the cargo carried as identified on AIS" however IMO categorization only gives letters to hazardous cargo and does not give a value for non-hazardous cargo therefore a default needs to be decided. Also since 2008 the IMO categorization has changed from "A, B, C, D" too "X, Y, Z, OS" which no longer works as a char type.