DDSXTY13 — Computation of KeyHash (7.6.7 Interoperability of Keyed Topics) needs additional detail

Section 7.6.7 (Interoperability of Keyed Topics) states that:

As described in [ RTPS ] Clause 9.6.3.3, “KeyHash (PID_KEY_HASH)”, the key hash for a given object of a keyed type is obtained by first serializing the values of the key members in their declaration order. The algorithm described in that clause shall be amended such that key member values shall be serialized in the ascending orders of their member IDs. For calculation of KeyHash for mutable types, the key members shall be serialized without any parameter encapsulation.

This statement does not explicitly say what to do about the DHEADER.

The section should be amended to state that the DHEADER should also not be serialized for the purpose of the KeyHash computation. This is consistent with the stated "design rationale" of making the computation should be platform independent. The DHEADER could create an ambiguity as it allows to specify an endianess which would result in different hashes if different endianess are used.

In addition it would be desirable to include examples where the types containing the keys are @appendable and @mutable. E.g.

@mutable
struct MyKeyedStruct {
    @key string name;
    @key long id;
    @long x;
    @long y;
};

Also we there should be an examples where the key fields themselves are declared as structures with extensibility @appendable or @mutable. E.g.

@mutable
struct MyOuterKeyedStruct {
    @key MyKeyedStruct inner_struct;
    @key long  another_key;
    @long z;
};

Subsumed by DDSXTY13-22

This issue has already been addressed by DDSXTY13-22