DDSXTY12 — TypeObject IDL and its propagation suffers from significant problems

The TypeObject IDL in Annex B has some significant problems:

• The TypeObject of a type embeds its TypeId. However to compute the TypeId one needs to serialize the TypeObject and hash the result. This recursion makes it impossible to create. The work around of first setting the TypeId=0, then computing a "adjusted" TypeObject, serialize and hash it, and use the hash of the "adjusted" TypeObject as its TypeId has been suggested but it is clunky to say the least.

• Even with the workaround mentioned above the TypeObject format cannot handle recursive types. That is types that refer to themselves which are legal in IDL. For example, there is no way to compute the TypeId of the "child" member f IntTree without having the TypeObject for IntTree which creates an infinite recursion.

typedef IntTree;
struct IntTree {
    long  value;
    sequence<IntTree> children;
};

• There TypeObject IDL uses extensibility(MUTABLE) for many types. This allows multiple equivalent serializations for the TypeObject as members of a mutable type can be serialized in any order. Also there is a choice between serializing them using so called short parameters or "extended" parameters, and also they can be serialized in big endian or little endian. All this means that the TypeId which is a hash computed on the serialized TypeObject can be different depending on how/where it is computed. This is undesirable as the TypeSystem uses the equality of TypeId to detect when types are identical.

• The TypeObject contains a very detailed representation of the type which is equivalent to the IDL and XML. This is propagated via discovery in the PublicationBuiltinTopic data. This information can be very large (100's of KB) which slows discovery and pushes information to every participant even if they have no interest on that Type, or already know it. Moreover, even when it is used the only need is to check type assignability and that does not require a lot of the information that is propagated with the type

• The TypeObject is missing the new annotations and types introduced in IDL4.

In view of this the TypeObject IDL should be refactored in a way that addresses the above problems. Moreover the specification should provide a more efficient way to propagate types that does not involve pushing the TypeObject in the discovery builtin topic data.

Refactor the TypeObject IDL definition and provide a more efficient propagation mechanism

This resolution includes:

• A new TypeObject IDL
• The computation of TypeId for mutually-dependent (recursive) types
• The propagation of TypeObject (using the request/reply builtin objects)
• The naming anonymous types.