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.

Section 6.2 contains two subsections that are specified as non-normative and six subsections which are not specified at all. Is one to assume that the six that are not specified are, in fact, normative? If so, they are certainly odd in that they do not include the kinds of things that might normally be considered normative, e.g., Dependencies. If not, then the reason for specifying the two as non-normative is mysterious. Similarly, section 6.4 as a whole is specified as non-normative. What are we to conclude, then, about 6.1 and 6.3? A related issue applies to the diagrams. Section 6.2.2 is not labeled "non-normative", however, figure 6.5, which is contained in 6.2.2 is so labeled. I am not sure how to understand this. Conversely, in Section 6.2.7, which is specified as non-normative, none of the diagrams are labeled "non-normative", in stark contrast to Section 6.2.1, where all diagrams are labeled to agree with the section.
Overall, this is minor, but the inconsistency/incompleteness of the labeling only increases the chances that a user will misunderstand the specification.

"An entity represented as a segment of the outline of an ellipse. It is defined by the ellipse it is part of and the start and end angle of the arc on that ellipse. The arc is defined in a clockwise direction from the startangle to the endangle."
Are startangle and endangle meant to reference the attributes in the table that follows or are they meant to be known terms? They either need a space or a capital letter depending on meaning.

Prior to 6.2.2
“A last (optional) channel allows both back-ends to exchange information preventing them to serve inconsistent data; this channel is, as of today, considered as proprietary but might be subject to a future standard or could use elements of TEX.”
There is no explanation why this is proprietary or how it could be standardized? Not sure why this statement was made.

1. There are no tables in the TOC, however section 10.6.2 Mapping has a large mapping table. This should be labeled and included in the TOC.
2. 6.2.5 Optional Capabilities
“Some capabilities have been considered as optional, meaning that conforming implementations are allowed not to implement them.”
Optional does not mean that they are NOT allowed to implement them. It means that they are not obliged to do so.
3. Several of the table rows in 7.3 cross pages. These should be modified so that they do not do so.
4. 7.4.8 STANAG2525CCategorizationData (Class)
The data needed for displaying the 2525C symbol set (TBD).
What does TBD mean in this context?
5. 7.4.9 STANAG2525DCategorizationData (Class)
This section has several blank lines and extra carriage returns. This should be cleaned up.
6. Is the standard APP6 or APP-6? Both are used throughout the document.
7. The table in Section 10.6.2 needs some sub-headings.
8. Misspelling prior to figure 6.4:
The “TACIST” back-end or TACSIT server that serves display data to the TACSIT component. This occurs a few times in the document.
9. 7.4.2 AISCategorizationData (Class)
“The IMO categorisation of the cargo carried as identified on AIS”. Some British spelling has crept in.
10. Section 10.6.1 seems to include an extra blank line between "…as NVG-formatted data." And "This PSM:"
11. There appears to be an extra blank line between the header for 12.3 and 12.3.1.

1. Why the hand drawings for section 6? It should certainly possible to do this in a drawing tool or PPT.
2. Figure 6.5
I am not familiar with the notation of connection interfaces to interfaces to interfaces. I think that this needs some explanation.
3. Diagram inconsistency:
I am a little puzzled about the diagrams contained in the specification on two fronts: 1. The diagrams in sections 6.x and section 7 are stylistically different. I trust that this is intentional as one reflects "Additional Information" and the other is the actual model, but this is only an assumption. This is not a problem, but it seems odd and unnecessary. 2. The quality of the diagrams differs significantly. The diagrams in 7 are clear at significant magnification whereas the diagrams in 6.x are not. In the publication process, this should be rectified.
4. Also, there is a use of color in the diagrams with no explanation as to what each color means.
5. Figure 6.6
What are the dashed boxes meant to represent? Not namespaces as stated in the text, but as they 6 packages are contained within the TACSIT package, what is the relationship with TCI and TEX?
6. Figure 6.11 – The 'TEX and TCI' Use pattern
What are the green and blue boxes under the TACSIT and other box? I am not familiar with this notation.
7. 7 Data Payload Platform-Independent Model
The word “gather” is used a few times in this section and other places. I think that “contain” would be better.