DDSXTY12 — Type system severely underspecified

In section 7.3.4.1.2 it is specified how to calculate the type ID for a given type. However, this algorithm heavily depends on the Type layout presented in Appendix B, which is not further explained. I have lots of questions about this algorithm, and am wondering if alternative mechanisms should not be considered instead.

1) Where does the hash that identifies the typeID of a constucted type come from?

It states that it comes from the Big Endian CDR respresentation of the type, which is an IDL representation of the model specified in Appendix B. However, this data model is not further explained, and far from mature and orthogonal. It looks like we created a pretty ad-hoc type system rather than deriving one from a well-designed meta-model with a minimal set of powerful transformation primitives.
There is a lot of existing documentation on how to set up a proper type-system. I suggest we consult some best-practices instead of re-inventing the wheel here.

2)The basis of the TypeObject consists of 2 fields, each having their own sequence. How the 2 sequences correlate is not further explained. The only thing that is explained in section 7.6.2.2 is that the the_type member of the TypeObject contains all types associated with the corresponding entity (1 for reader/writer, more for topic). I think it would be better to take this sequence outside TypeObject and give Topic a sequence of TypeObjects instead.

TypeId algorithm proposed

See RTI's TypeId proposal attached to Issue #7: TypeId calculation errors/corrections. TypeId computation has been unambiguously specified.