DDSXTY12 — TypeId calculation errors/corrections

Section 7.3.4.1.2 Type Hierarchy in the XTypes spec explains how to calculate the TypeId for a given type.
The description provided contains errors and ambiguities that must be resolved.
1.- The spec explains that the TypeId of a constructed type is calculated by serializing the type in big-endian CDR data representation. However, the TypeId itself is part of the Type (ArrayType, StructureType). We cannot serialize without the TypeId and we cannot get the TypeId without serializing.
To resolve this problem I am setting the Type's TypeId to the following value before serializing:
RTI_CDR_TYPE_OBJECT_NO_TYPE (for the discriminator)
RTI_CDR_TYPE_OBJECT_NO_TYPE_ID (for the union value)
2.- The Type (ArrayType, StructureType) also has a member containing the type name (not fully qualified). The value of this member is used to calculate the TypeId. Since the name is not fully qualified, two identical types within different modules will have the same TypeId. The question is whether or not the type name should be used as part of the TypeId calculation.
If the type name must be used as part of the calculation and it discriminates, then we will have to use the fully qualified name. Otherwise two identical types within different modules would get same TypeId.
If the type name should not be used as part of the calculation then we can set it to the empty string for TypeId calculation purposes.
According to the XTypes spec:
"To allow types to refer to one another unambiguously, a given TypeId value shall uniquely identify a type within the TypeLibrary contained by a TypeObject object and in any other Type Libraries contains recursively therein. It shall have no narrower scope. There is no restriction that a type's definition must occur a TypeId reference to it; there is no concept of a forward declaration in this Type Representation."
Therefore, two types within the library should not contained the same TypeId.
3.- Also, the serialization in BigEndian of the TypeObject is not guaranteed to be the same across different DDS vendors since the TypeObject itself is a mutable type and therefore it requires parametrized encapsulation for its members. The choice of extended versus not extended parameter encapsulation may be different across different DDS vendors.

New TypeID computation algorithm

The previous algorithm included in the specification is not implementable because it causes inadvertent recursive dependency of type-id on themselves. The new computation of the TypeId has been defined such that all vendors compute the same values for the same types. See section 7.3.4.1.2 in the specification document.