// Unions with extensibility MUTABLE, version 2 encoding
// see (22) for serialization of MMEMBER using version 2 encoding
(27) XCDR[2] << {O : MUNION_TYPE} =
 XCDR
 << { DHEADER(O) : UInt32 }
 << { O.disc : MMEMBER }
 << { O.selected_member : MMEMBER }?

The specification says the discriminator should be treated as an MMEMBER, but it is not clear what the member ID of the discriminator should be. This has caused interoperability issues as different vendors are using different IDs.

In Kongsberg's implementation, we've been using 0 for the discriminant. The first member of the union has thus had the member ID 1 (assuming @autoid(SEQUENTIAL)).

The description of PUSH states:
```
Pushes the specified XCDR stream variable VARIABLE
into the stack and sets the current value to <newvalue>.
The notation <?> indicates that the new value can be
chosen by the implementation.
This action is reverted by the POP() operation
```
However the first serialization rule that writes the HEADER calls `PUSH(ORIGIN=0)` after writing the ENCHEADER, even though it's already been set to 0 on initialization. PUSH(ORIGIN=0) is also called after writing PL_CDR headers. I'm confused as to what this is supposed to mean. Based off of the current definition of PUSH I would be lead to believe that it truly does set the origin equal to 0. However looking at it's usage I would think that PUSH(ORIGIN=0) should mean that the origin is reset to where the current offset is, and based of of what I've seen in PL_CDRv1 messages with 8 byte members, this has been a correct assumption.
Another confusing element around the usage of PUSH is that I don't see POP used anywhere in the Serialization rules.

The [RTPS] version referenced in section 3 is version 2.2. It should be updated to version 2.3.
The reference to [RTPS] in [RTPS] Clause 9.6.3.3, “KeyHash (PID_KEY_HASH)”, should change to [RTPS] Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)”. This is because the section number changed in RTPS 2.3.

Section 7.6.7 was not fully updated to account for CDR version 2. For example it does not clearly state whether DHEADER is serialized for the purposes of computing the KeyHash.

Also the sentence about backwards compatibility is no longer relevant.

The decision of whether to serialize DHEADER or not should be taken as soon as possible as it would affect interoperability.

Update 7.6.7 with more complete description of KeyHash computation

Update section 3 [RTPS] to reference version 2.3.

Define the KeyHash computation in a more unambiguous as described below.

Take the AggregatedType "Foo" that is the container of the key members for which we want to compute the key hash.
For the purposes of computing the key hash, define a key holder type FooKeyHolder as follows.

• Start with the original Foo type
• Remove any no-key members
• Reorder the key members in the order of memberId (this handles the cases where the AggregateType is Final/Appendable/Mutable).
• Apply this recursively to the types of the key members if they are of an AggregatedType.

Consider FooKeyHolder (and any KeyHolder types resulting from key members that were of an AggregatedType) as having @extensibility(FINAL).

After FooKeyHolder has been constructed. We have two cases:

(a) If the maximum Serialized Size of FooKeyHolder <= 16 then KeyHash = CDR_BigEndian(FooKeyHolder)
(b) If the maximum Serialized Size of FooKeyHolder > 16, then KeyHash = MD5(CDR_BigEndian(FooKeyHolder))

CDR_BigEndian uses XCDR version 2 encoding rules and assume serialization on a 4-byte aligned buffer.

Therefore the resulting serialized type does not have any encapsulation header, not any DHEADER (from Appendable/Mutable types) nor any MemberHeader (from Mutable types), and uses a maximum alignment of 4-bytes.

Assume the following:

@appendable
struct T1 {
   @key long m1; 
}

@appendable
struct T2 {
  @key long m2;
  @key long m3;
}

struct MyType1  {
  T1 t1; 
  long ll1;
} 

struct MyType2  {
  T2 t1;
  long ll1;
}

According to the type-compatibility rules MyType1 and MyType2 are not compatible because T1 is not compatible with T2.

The reason T1 is not compatible with T2 is due to having different keys. But the keys of T1 and T2 do not play any role in MyType1 and MyType2 because these types did not declare those respective member as key.

So the current compatibility rules are too restrictive. They should be amended to allow MyType1 and MyType2 to be compatible.

Modify type compatibility rules for Aggregated Types

Modify the type assignability rules to differentiate the requirements form members that are part of the key of the aggregated type from those that are not part of the key.

The assignability of members that are not part of the key of the enclosing type should not take into consideration the key members of the nested type.

A dynamic type cannot be marked as final, mutable or nested and a dynamic type member cannot be marked as key, optional, shared or must_understand easily with the current specification. Only MemberDescriptor has a boolean field "union_default" to represent whether the union member is the default one. Annotations can be used of in the dynamic API but the usage is a bit cumbersome. Is it considerable to append TypeFlag and MemberFlag fields to TypeDescriptor and MemberDescriptor in order to represent built-in annotations in dynamic types as in TypeObject?

TypeDescriptor and MemberDescriptor with information about the built-in annotations.

As indicated in the issue description, the MemberDescriptor and TypeDescriptor types need additional members that provide the value of the builtin annotations.

Define an enum for TypeKind. This was referenced in TypeDescriptor and MemberDescriptor but never defined.
Define an enum for ExtensibilityKind
Define an enum for TryConstructKind
Define VerbatimTextDecriptor

Add the following fields to MemberDescriptor: is_key, is_optional, is_must_understand, is_shared, try_construct_kind

Add the following fields to TypeDescriptor: is_nested, extensibility_kind

The specification is not explicit about which Types may be used for a DDS Topic.

By convention most DDS implementations have supported structures. However it is not clear if unions are allowed. And even less so if collections, strings, or primitives can be used.

Annex E: Built-in Types defines as builtin the types: String, KeyedString, Bytes, and KeyedBytes.

The DDS specification also does not say anything explicitly. However the fact that it talks about the type-specific code for a type "Foo" namely "FooSupport" "FooDatWriter", etc. may be taken to imply that this must be constructed types that are given a name. e.g. "Foo" by the user. And not primitive types.

It would be better if the XTYPES spec was explicit about this.

Specify that only Aggregated Types (structure and union types) may be used as a DDS Topic Type

Aggregated Types are the only ones that have members and allow the possibility of specifying a Key. For this reason the are the only ones suitable for being Topic-Types.

Specify this restriction following section 7.6.1 'Topic Model'.

This issue was incorrectly entered. It was an attempt to create a proposal for DDSXTY13-1 which ended up creating a new issue.

Duplicate of Issue DDSXTY13-1

Duplicate of Issue DDSXTY13-1

The AB review identified two critical issues with the XSD changes made by various issue resolutions that need to be fixed:

• The resolution of DDSXTY13-1 modified the definition of xs:group moduleElements and changed the name of the first element from "include2" to "include" this causes the XSD to be invalid because it conflicts with the name of another element in the definition of xs:complexType moduleDecl
  . This change should be reverted.

• The resolution of DDSXTY13-4 updated the file "DDS XTypes 1.3 XML Type Representation, No Namespace, Schema file" removing default values for attributes. However it failed to update the contents of Annex A with contain the same XSD definitions.

• The attribute value minOccurs="1" is unnecessary for element declarations because it matches the default value when the attribute is not specified. It should be removed from Annex A and the file "DDS XTypes 1.3 XML Type Representation, No Namespace, Schema file"

Update Annex A and the "XML Type Representation, No Namespace, Schema file"

Apply the corrections indicated in the issue description.

Sections 7.3.1.2.3 'Alternative Annotation Syntax' and 7.3.1.2.6 'Alternative Syntax' contain identical contents. It seems like the section was moved and one was not properly removed.

One of this two sections should be deleted.

Remove 7.3.1.2.6 'Alternative Syntax'

It is better to keep 7.3.1.2.3 'Alternative Annotation Syntax' and remove 7.3.1.2.6 'Alternative Syntax' because section 7.3.1.2.3 references the alternative annotation syntax.

Therefore the resolution of this issue should just remove section 7.3.1.2.6 'Alternative Syntax'

Add the @data_representation annotation as proposed in the issue description. Also clean up the terminology when talking about PLAIN_CDR, PL_CDR, etc. refer to those as "encodings" rather than "representations"

Duplicates DDSXTY13-46

Close as duplicate

Currently the DataRepresentation (XCDR1, XCDR2, XML) is controlled by a Qos Policy on the DataWriter. This is good to allow run-time configurability and enable systems to evolve.

However when defining data models for systems that will be deployed it may be important to allow that representation to be declared and restricted in the data-model. This may be needed such that the users of that data model can be sure to interoperate with the deployed system. This also supports the use-case where systems are deployed with code that support only one representation as may be the case in some resoure-constained systems.

A proposed solution is to add an annotation:

enum DataRepresentationKind {
    XCDR_AND_XCDR2,
    XCDR,
    XCDR2,
    XML
};

@annotation data_representation {
    DataRepresentationKind value default XCDR1_AND_XCDR2;
};

If @data_representation is not specified then the default is XCDR_AND_XCDR2. This allows the representation to be configured on the DataWriter and DataReader DataRepresentationQos policy.

If a value other than XCDR_AND_XCDR2 is specified, then that setting overrides the DataRepresentationQos that may have been set on the DataWriter or DaraReader.

In addition the terminology for 7.4.x could be cleaned up a bit. Fist it cases about XCDR and XML as being "Data Representations" however later on it talks about PLAIN_CDR and DELIMITED_CDR, PL_CDR2 also as "representations". It may be better to use a different word for this to avoid confusion.

Keep "Representation" for XCDR, XCDR2, XML, etc. This is consistent with the Qos policy and the main definitions. Use another word. For example "encoding" to talk about PLAIN_CDR, PL_CDR, etc.

Define a @allowed_data_representation annotation

Add an annotation that can be applied to types and modules that restricts the data representations that a type may use.

The definition should be as proposed in the issue description.

Section 3. 'Normative References' points to older versions of IDL ad DDS. Update those references the latest version.

Update Normative references

Update DDS to DDS 1.4 https://www.omg.org/spec/DDS/
Update IDL to IDL 4.2 https://www.omg.org/spec/IDL/

The compatibility for structure in section 7.2.4.4.8 'Aggregated Types' would make two structures that have a key member of type string compatible even if the keys had different maximum lengths.

This is problematic. It would result in potentially aliasing different objects and also in different decisions on how the KeyHash is computed.

Duplicates DDSXTY13-21

Duplicates DDSXTY13-21

Section 7.2.2 should include all the Type-System concepts that are related to all the "relevant" annotations in IDL 4.2 (likely groups for "General Purpose", "Data Modeling", "Units and Ranges", "Data Implementation", and "Code Generation") in addition to extra concepts in XTYPES that are not part of IDL4 like Try Construct Behavior, Non-Serialized.

After 7.2.2.6 Annotations there should be a section on the "Builtin Annotations" these should references the ones IDL 4.2 as well as the extra ones in XTYPES.

Much of the text in existing section 7.3.1.2.1 should me moved to 7.2.x. These are general concepts independent of the use of IDL.

Table 7.3.1.2.2 Using Built-in Annotations should be also moved to 7.2.2.x.

In place of 7.3.1.2.1 there should be a table that maps the "builtin" annotations in the XTYPES type system to their IDL4 syntax. For the most part this references the corresponding annotation in IDL 4.2 except for the new ones introduced by XTYPES.

7.3.2.x and Annex A should define how the builtin annotations are represented in XML.

Annex B should be augmented with any missing annotations. It appears @default is missing from the COMPLETE TypeObject.

Defer to the next RTF

This reorganization is worthwhile but it would introduce a lot of changes that overlap with those of other issue resolutions. Therefore it is best deferred to the next RTF.

Table 19, on the compatibility of STRUCTURE_TYPE it says:

AND if T1 is appendable, then any members whose member ID appears both in T1 and T2 have the same setting for the ‘optional’ attribute and the T1 member type is strongly assignable from the T2 member type.

This is missing the rule about members having that have the same ID must also have the same index. This rule was present in version rsion xtypes v 1.1 and somehow was lost in version 1.2.

*Edit Table 19, rule for STRUCTURE_TYPE *

Edit Table 19, rule for STRUCTURE_TYPE adding that for APPENDABLE and FINAL the member indices must match.

The resolution of DDSXTY12-18 was not applied correctly to section In Section 7.6.2.1.1 (DataRepresentationQosPolicy: Conceptual Model).

According to that resolution the bullet below:

• Readers belonging to implementations of XTYPES version 1.2 and later:

Should appear directly above the 3 sub-bullets that start with:

• • Shall generate or include run-time code that can deserialize version 2 encodings.

However in the final document that bullet is missing.

Add the missing bullet to Section 7.6.2.1.1

Add the missing bullet per issue description.

7.2.1.1 (Type Evolution Example) pg 13 first para

> [ ...] However, not all components that publish or subscribe data of this
> type will be upgraded to this new definition of VehicleLocationType
> (or if they will not be upgraded, they will not be upgraded at the same
> time)

• (or if they will be upgraded, they will not be upgraded at the same time)

7.2.1.3 (Sparse Types Example) pg 14 first para

> [...] In its local programming language (say, C++ or Java), the
> application can assign a pointer to null to omit a value for these fields.

• the application can assign null to a pointer to omit [...]

7.2.2.2 (Primitive Types) pg 18 Table 3 description for INT_16_TYPE

> Signed integer minimally capable of representing values in the range
> -32738 to +32737.

• -32768 to 32767.

7.2.2.2.1.2.1 (Use of Unicode) pg 20 fourth para

> [...] The UTF-8 representation ISO-8859-1 characters that are not in the
> ASCII subset uses two 8-bit code units.

• The UTF-8 representation of ISO-8859-1 characters [...]

7.2.2.2.1.2.5 (CHAR_16_TYPE) pg 21 Rationale second para

> [...] Restricting to the BMP ensures that each coodepoint is [...]

• codepoint

7.2.2.7 (Try Construct behavior) pg 42 first para

> [...] Similar to the structure examples there exist be objects of type
> SEQ1024 [...]

• [...] there may exist objects of type SEQ1024 [...]

7.2.4.1 (Constructing objects of one type from objects of another type)
pg 46 Table 13 column "Type compatibility" bottom

> All objects of type T1 can either be used to
> construct an object of type T1 or reliably de-
> tected that that cannot initialize T1. .

Please check - my guess is:

• [...] construct an object of type T2 or it can be
  reliably detected which objects of type T1 cannot initialize T2.

7.2.4.4.5.1 (Example: Strings) pg 49 first para

> [...] If a
> consumer of strings of narrow characters were to attempt to consume
> that string, it might read
> consider the first byte of the first character [...]

• Omit the word "read" :
  [...] were to attempt to consume that string, it might consider [...]

Table 19 (Definition of the is-assignable-from relationship for aggregated types)
pg 53 second column fourth (i.e. last) bullet

> If T1 (and therefore T2)
> extensibility is final then the set of
> labels are identical.

• [...] then the set of labels is identical.

7.3.1.1.1 (Backward Compatibility with Respect to Type Definitions)
pg 60 bullet "Group of Annotations" fourth sub-bullet

> * Code Generation (sub clause 8.3.5 [IDL41]) his specification retains
> well-
> established IDL type definition syntax, such as enumeration, structure,
> union, and
> sequence definitions.

Appears to be a formatting problem, I think the last part of that phrase should be outside and after the end of the bullet enumeration:

• Code Generation (sub clause 8.3.5 [IDL41])

This specification retains well-established IDL type definition syntax, such as enumeration, [...]

7.3.1.2.2 (Using Built-in Annotations) pg 70 first sentence

> The application of the annotations listed above is restricted to the
> elements of specified in Table 21.

• [...] is restricted to the elements of IDL specified in Table 21.

7.3.1.10 (Structure Types) pg 76 first sentence

> Structures as described in this specification are in this specification are
> fully compatible with the IDL constructs of the same name.

• Structures as described in this specification are fully compatible [...]

7.3.1.11 (Union Types) pg 76 first sentence

> Unions as described in this specification are in this specification are
> fully compatible with the IDL constructs of the same name.

• Unions as described in this specification are fully compatible [...]

7.3.2.4.3 (Map Types) pg 80 first bullet

> * The map’s bound, if any, shall be indicated by the mapMaxLength
> attribute. This attribute is required for all map types.

For more fluent reading, I suggest:

• The map's bound shall be indicated by the mapMaxLength attribute.
  This attribute is required for all map types.
  In case of an unbounded map, mapMaxLength shall be set to "-1".

7.3.2.4.3 (Map Types) pg 81 non-normative example:

> <struct name="MyStructure">
> <member name="my_unbounded_maps_of_integers_to_floats"
> type="int32"
> mapKeyType="float32"
> mapMaxLength="-1"/>

The values for "type" and "mapKeyType" are swapped, they should be:

• type="float32"
• mapKeyType="int32"

7.5 (Language Binding) pg 133 top of page (2nd sentence)

> The main characteristics and motivation for each of these binding are
> described in Table 41.

• [...] for each of these bindings are described in Table 41.

Perform the corrections suggested in the issue description

Perform the corrections indicated in the issue description.
Note that some of the issues indicated in the description were already resolved as part of the editorial corrections performed by OMG editors. This issue addresses the ones that were not caught in that step.

In the DDS-XTypes 1.2beta1 document, the UML class diagram in section 7.5.2.8 Figure 30 on p. 175 does not show the multiplicity relationship between DynamicType and DynamicTypeMember for the case of aggregated types.
In other words, the fact that a DynamicType struct/union/valuetype may have more than one member is not visible in the diagram.

The section 7.5.2.9 DynamicTypeBuilder does define an operation add_member which can be used to add members to aggregated types. However, DynamicTypeBuilder also does not provide a method for iterating over the members thus added.

If it is intended that the management of and iteration over the sequence of DynamicTypeMembers shall lie outside of DynamicType / DynamicTypeBuilder, I suggest adding an explanation to that end.

Update Figure 30 'Dynamic Type' and operations of DynamicTypeBuilder and DynamicType

Update the of multiplicity of DynamicTypeMember in Figure 30 'Dynamic Type' (section 7.5.2.8) from "0..1" to "0..*"

Add operations to 7.5.2.9 'DynamicTypeBuilder' that allow figuring out the number of members and iterate over them.
Add operations to 'DynamicType' to find the number of members and iterate over them.

Order operations alphabetically.

The DDS Type System does not provide a way to represent signed and unsigned 8-bit integers. IDL 4.2 has introduced the int8 and uint8 types for this purpose, but DDS-XTYPES is still missing those in the model.

Support for 8-bit signed and unsigned integers is required by some RFP submissions, such as the OPC UA/DDS Gateway RFP.

Include support for signed and unsigned 8-bit integers

Add two primitive types: Int8 and UInt8 (INT8_TYPE and UINT8_TYPE) to the type system in section 7.2.x

Add these two types wherever Integer Types are used.

Use the IDL int8 and uint8 to represent them in in the IDL Type Representation (section 7.3.1.x).

In the XML Type Representation (section 7.3.2.x) use "int8" and "uint8" as the XML Type Representation name (Table 26).

Add support for these two types to the TypeIdentifier and TypeObject (section 7.3.4.x)

Add the rules to serialize those types to 7.4.x
Add the language mappings to 7.5.1.1.x

Add these two types to Annex A, Annex B, Annex C.

Mention in F.1 that legacy implementations do not support int8 and uint8.

The XML type representation (Section 7.3.3) has an associated XSD that defines the legal XML documents that define DDS Types.

In the XML type representation builtin annotations on members appear as "attributes" on the element that describes the member. For example see example in section 7.3.2.5.1.2 (Members):

<struct name="structMemberDecl">
   <member name="my_key_field" type="int32" key="true" optional="false"/>
</struct>

These builtin annotations (key, optional), have default values when they are not present. This is defined in the IDL4+ specification. For example when the annotation "key" is not present, the (default) value is "false" when annotation "optional" is not present, the (default) value is "false". There is also a "default" value when the annotation is present with no parameters, but this is not allowed in the XSD.

According to the XSD syntax, e.g. see https://www.w3schools.com/xml/schema_simple_attributes.asp

The "default" value specified for an attribute is the value interpreted when the attribute is not present. Therefore we have two options:

• Have the XSD specify default values for these attributes to match the "IDL4+ defaults when the attribute is not present

• Have the XSD specify no default value.

Currently this is not done correctly for some annotations. For example the XSD for structure members has wrong defaults for all the attributes:

  <xs:complexType name="structMemberDecl">
    <xs:complexContent>
      <xs:extension base="memberDecl">
       <xs:attribute name="id"
                     type="memberId"
                     use="optional"/>

        <xs:attribute name="optional"
                      type="xs:boolean"
                      use="optional"
                      default="true"/>
        <xs:attribute name="mustUnderstand"
                      type="xs:boolean"
                      use="optional"
                      default="true"/>
        <xs:attribute name="nonSerialized"
                      type="xs:boolean"
                      use="optional"
                      default="true"/>
        <xs:attribute name="key"
                      type="xs:boolean"
                      use="optional"
                      default="true"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

However it seems like the best solution is to remove the specification of a default value from the XSD. The problem is that when the default is specified the XSD parsers will fill the default value even if the attribute is not specified and it becomes impossible for the application that uses the parser to know if the attribute was there or not in the first place. This would make it impossible to transform between IDL and XML and back to IDL and get the same result back because all annotations would appear present to the XML parser even if they were not entered buy the user.

Therefore we recommend removing the specification of 'default" value for all XML attributes that correspond to builtin annotations. This should be done both in Annex A and the machine readable dds-xtypes_type_definition_nonamespace.xsd

*Remove the 'default" value for all XML attributes that correspond to builtin annotations. *

For the reasons listen in the issue description the XSD should not specify any default values for XSD attributes that correspond to builtin annotations.

The specification does not define how memberIDs are computed in the case where the @autoid (or @hashid) annotations are used. This is needed for interoperability.

Section 7.3.1.2.1.1 (Member IDs) specifies there are thee ways to set them:

• Automatically following a progression that starts from the most-recently specified member ID.
• Using the @id annotation
• As a "hash" on the member name when @autoid(HASH) is specified
• as a "hash" on a string-parameter when @hashid("string-parameter") is specified

The use of @autoid refers to sub clause 8.3.1.2 in [IDL41]). But there also there is no specification of how the hash should be computed. Only that a "hashing" algorithm should be used.

IDL working group discussed this and the preference was to leave it unspecified in IDL4 and instead put it in XTYPES or whichever specification depends on these IDs.

A proposal would be to use an MD5 (as this is already used for key hashing).
This needs to be done in a platform-independent manner, for example hashing a serialized representation of the string using a pre-specified endianness. Also per section 7.2.2.4.4.3 (Member IDs) the value/range must be representable in 28 bits.

Use the same hash algorithm specified for the TypeObject (Minimal)

The (normative) IDL for the TypeObject (Minimal Representation) already requires hashing of member names. This is exercised in the (non-normative) example serializations included as part of XTYPES 1.2.

The algorithm used for this hashing of member names is described as a comment in the dds-xtypes_typeobject.idl

    // First 4 bytes of MD5 of of a member name converted to bytes
    // using UTF-8 encoding and without a 'nul' terminator.
    // Example: the member name "color" has NameHash {0x70, 0xDD, 0xA5, 0xDF}
    typedef octet NameHash[4];

Although this hash algorithm is only specified for the TypeObject and not the MemberId it would make things simpler to use the same algorithm for the @autoid and @hashid. It is also more efficient that doing a CDR serialization because it saves the length and the trailing NUL.

We still need to specify how to transform the octet[ 4 ] NameHash into a integer memberId with 28-bits of precision so we can all the 4 bits of flags specified in the MemberId format. This basically requires interpreting the NameHash as having a specific endianness.

Section 7.6.2.3.3 'TypeLookup Types and Endpoints' provides some examples of NameHash that use Big Endian. For example it says that @hashid("getTypes") is a long with value = 0xd35282d1. Note that the md5("getTypes") is the octet sequence d35282d177f1c8e43144c7e65820d7ae. So value = 0xd35282d1 corresponds to the first 4 bytes interpreted as a BigEndian.

Therefore an Endianess needs to be specified such that an octet[ 4 ] containing the first 4 bytes of the MD5 can be interpreted as an integer. For example if we had chosen Little Endian the NameHash =

would be interpreted as the integer: 0xDFA5DD70.

We still need to zero 4 bits of this to truncate it to the 28 bits of the memberId and allow the addition of the must-understand flag (M_FLAG) and the length code (LC).

Table 39 in section 7.4.3.3 specifies that the enhanced mutable header is computed as:

EMHEADER1 =  (M_FLAG<<31) + (LC<<28) + M.id

This means that we need to clear the 4 most significant bits from the member id (bits 29-32).

The resolution is to explicitly provide the algorithm used to compute the member ID from a NameHash. This algorithm interprets the NameHash as a Big Endian integer. Using C pseudo code the construction of the member_id from a NameHash would be as follows:

    uint32_t  hash_as_int;
    uint32_t  member_id;

#ifdef (MACHINE_IS_BIG_ENDIAN)
    hash_as_int = *((uint32_t *) NameHash);
#else
    hash_as_int = *((uint32_t *)EndianessSwap4Bytes(NameHash));
#endif

// Truncate to 28 bits removing the 4 most significant bits
member_id = hash_as_int & 0x0FFFFFFF;

In the case of member name "color" we would have:

NameHash = { 0x70, 0xDD, 0xA5, 0xDF } 
hash_as_int = 0x70DDA5DF
member_id  = 0x00DDA5DF

Assuming we have M_FLAG = 1, LC = 1, we would have:

EMHEADER1 = 0x90DDA5DF

EMHEADER1 is then serialized on the wire using Little Endian format (as specified by the TypeObject serialization) so the bytes on the wire would end up being:

{0xDF, 0xA5, 0xDD, 0x90} 

Alternatively (currently favored by Task Force)
We could define the transformation of NameHash to MemberId using LittleEndian. This will save the byte swap done at serialization time. An also save the initial on in LittleEndian machines (which are the most common). So this seems a more optimized approach.''

In this case member name "color" we would have:

NameHash = { 0x70, 0xDD, 0xA5, 0xDF } 
hash_as_int = 0xDFA5DD70
member_id  = 0x0FA5DD70

If we go with this we need to change the examples in section 7.6.2.3.3 'TypeLookup Types and Endpoints'

NameHash("getTypes") = {d3, 52, 82, d1}
NameHash("getDependencies") = {31, fb, aa, 35}
Also change the example to be unsigned long:

const unsigned long TypeLookup_getTypes_Hash = 0x018252d3; // @hashid("getTypes")
const unsigned long TypeLookup_getDependencies_Hash = 0x05aafb31; //@hashid("getDependencies"); 

In Section 7.2.3, Table 12 in the rows for "Collection Types", "String Types", and "Primitive Types" should add that "For these types the extensibility kind has no effect in the type matching."

In Section 7.2.3, Table 12 the row for "Bitmask" says it is always final. This seems limiting, should be like Enum and allow "final" or "appendable"

In figure 11, 12 and the XSD it shows extensiblity_kind=FINAL for enumerations. This is wrong and inconsistent with 7.2.3.

The XSD does nor allow setting the "extensibilty" for the "enumDecl". It should.

In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.
Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.

In section 7.3.4.4 'Minimal TypeObject' the last paragraph starts with "The complete TypeObject" it should start with "The minimal TypeObject"

In Annex B in the IDL comment for AppliedBuiltinMemberAnnotations refers to “@hash_id” as opposed to “@hashid”, which is the actual annotation name. Every reference to “@hash_id” should be modified to refer to "@hashid."

Typo in section 7.2.3 (Type Extensibility and Mutability) it says "APENDABLE" instead of "APPENDABLE"

Typo in XSD says "include2" instead of "include"

Perform the corrections listed in the issue description

Perform the corrections listed in the issue description

As the spec is currently written, section 7.6.2.1.2
'Use of the RTPS Encapsulation Identifier', it is ambiguous as to which bits are used to encode the padding bytes.

RTPS 2.4 is redefining the options field to be an array of two octets rather than a ushort. So XTypes should specify that the lower-order two bits of options[1] are used to encode the number of padding bytes.

Modify 7.6.2.1.2 'Use of the RTPS Encapsulation Identifier'

Modify 7.6.2.1.2 'Use of the RTPS Encapsulation Identifier' to indicate that the options field is octet[2] and that the bits using for padding are the least significant bits of the second byte:

0...2...........8...............16..............24..............32 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|   representation_identifier   |               |            X X| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The presence of a bit indicating the endianess in the DHEADER causes serious inefficiencies in the serialization.

• When mutable encapsulation is used, the length of the member can be shared between the MemberHeader and the MemberSerialization in the case where the MemberSerialization starts with a length. This would be the case for strings and octet sequences. If the DHEADER did not have the EndianessBit then this optimization would also apply to the @appendable members which is a very common use-case.

• The processing of the Endianess bit (pack/unpack) and check takes CPU time. This would be avoided if the Endianess bit is not present.

The reason why the Endianess Bit was put was to support embedding serialized data inside other serialized data even if the pieces came from different endianess. This is not a common use-case. Supporting this edge case is not worth hurting the performance of the common case.

The proposal is to remove the Endianess Bit from the DHEADER.

Remove E_FLAG from DHEADER

Redefine the DHEADER used for Appendable and Mutable types to only contain the length of the serialized object that follows (O.ssize).

This affects the following parts of the specification:

• Table 39 ('Functions operating on objects and types'. The entry for DHEADER shall be changed to just say DHEADER(O) = O.ssize

• Section 7.4.3.4.1 'Delimiter Header (DHEADER)' remove mentions of the
  E_FLAG.

• Section 7.4.3.5.3 'Complete Serialization Rules'. Replace "DHEADER(O, <E>)" with "DHEADER(O)" this affects rules (9), (12), (15), (21), (27), (30).

In order to use an IDL type as a topic type, some additional methods are required to be generated (such as methods for creating DataReaders and DataWriters).

Implementations have invented their own mechanisms in this area:

• One product might support the notion that by default all structured types can be used as topic types, defining a mechanism to selectively switch off that assumption
• Another product might require a pragma to be used for switching on the additional code generation for topic types

A built in annotation should be added for distinguishing topic types from non topic types.

Introduce a @DDSTopic annotation that allows marking DDS Topic Types

Define a new annotation that can be used to indicate that certain types are intended to be used as DDS Topic Types.

There are some related precedents:

DDS-RPC

This @DDSTopic annotation parallels the @DDSService annotation defined in DDS-RPC. The definition is of @DDSService

@annotation DDSService {
    string name default "";
};

Note that DDS-RPC also defines the following annotations:

module dds { module rpc {
@annotation DDSRequestTopic {
    string name;
};
@annotation DDSReplyTopic {
    string name;
};

};};

IDL 4.2
This specification which was released after DDS-RPC introduced a new notation for marking services:

@annotation service {
string platform default "*";
};

In IDL42 there are three pre-defined values of for the platform:

• "CORBA" indicates that the service should be made accessible via CORBA.
• "DDS" indicates that the service should be made accessible via DDS.
• "*" (an asterisk) indicates any platform. This is the default value.

So a definition that follows what was done in DDS-RPC could be:

@annotation DDSTopic {
    string name default "";
};

Whereas a definition that follows what was done in IDL 4.2 could be:

@annotation topic {
   string platform default "*";
};

Or some other name instead of "topic", perhaps "message" if we consider it sufficiently generic:

Note that all MQTT (http://mosquitto.org/man/mqtt-7.html), Amazon Pub-Sub (https://aws.amazon.com/pub-sub-messaging/), and Google PubSub (https://cloud.google.com/pubsub/docs/overview) use the concept of messages sent to a Topic.

If we used a @topic definition in IDL and we wanted to be able to specify the Topic name would need to combine it with another annotation (in DDS-XTYPES, not IDL) to do this. For example @DDSTopicName. So finally we would have:

IDL4 -> @service , @topic. These allow specifying the platform, e.g. @service("DDS") or @topic("DDS"). If not parameter is specified the default is @service("*"), @topic("*").
Then in DDS-RPC we have @DDSServiceName("MyService"), @DDSRequestTopic("MyServiceRequest"), @DDSReplyTopic("MyServiceReply")
Ans in DDS-XTYPES we have @DDSTopicName("MyTopic").

Alternatively we could try to eventually push all this into the IDL annotations. For example:

@annotation service {
     string platform default "*";
     string name default "";
     string request_topic default "";
     string reply_topic default "";
};

@annotation topic {
     string platform default "*";
     string name default "";
};

So for now we could add @topic to the DDS-XTYPES and push it to IDL4 later.

How would annotations with parameters appear in XML? Is it legal to do something like:

<struct name="Shape"  topic.name="Square" topic.platform="DDS">
    <member name="color" type=string"/>
 </struct>

> 2.2.2 Basic Network Inteoperability Profile

• "Interoperability"

> 7.2.3 Type Extensibility and Mutability
> [...]
> • A type may be APENDABLE,

• "APPENDABLE"

> [...]
> It is summarized more enerally in Table 12.

• "generally"

> 7.2.4.4.1 Assignability of Equivalent Types
> If two types T1 and T2 are equivalent according to the MINIMAL relation (see Section 7.3.4.7),
> then thery are mutually assignable,

• "they"

> Table 15 – Definition of the is-assignable-from relationship for primitive types
> [...]
> UINT64_TYPE
> BITMASK_TYPE if and only if
> T2.bound is between 33vand
> 64, inclusive.

• "between 33 and 64"

> Table 20 – Alternative Type Representations
> [...]
> XSD [... 2nd column]
> [...] No direct support for many of the
> contructs (e.g keys) or the types in
> the type model

• "constructs"

> 7.3.4.6.2 Hash TypeIdentifiers
> Some TypeIdentifiers include within (directly or indirectly) hashes of one of mre
> TypeObjects.
Phrase is unclear, please reword.

> 7.3.4.6.4 Indirect Hash TypeIdentifiers
> These are the HASH [...] using a hash
> TypeIdentifiers . They are distinghished byt:

• "They are distinguished by:"

> 7.4.1.1.1 Primitive types
> [...]
> • An endianness byte swap shall be performed in case the native system endianness is dif-
> ferent from the one currently configured in the XCDR stream (XCDR.cendien).

• "XCDR.cendian"

Correct the typos

Perform the typographical corrections indicated in the issue description.
Note that some of the issues indicated in the description were already resolved as part of the editorial corrections performed by OMG editors. This issue addresses the ones that were not caught in that step.

Section 7.5.2.5 (MemberId) states that

The type MemberId is an alias to UInt32 and is used for the purpose of representing the ID of a member of a structured type.

However it is clear from the serialization rules in 7.4.3.4 and specifically the definition of EMHEADER1 in table 39:

EMHEADER1 = (M_FLAG<<31) + (LC<<28) + M.id 

Where:
M_FLAG is the value of the Must Understand option for the member
LC is the value of the Length Code for the member.

That MemberId are restricted to a 28-bit range. This should be clarified in the specification.

Furthermore the specification should make it clear that the M_FLAG is not introducing a separate "space" of member IDs. So a type cannot have two members with the same value of the 28-bit memberID even if one has M_FLAG=1 and the other M_FLAG=0.

Additionally in section 7.4.1.2.1 (Interpretation of Parameter ID Values) where it talks about PID_EXTENDED it states:

The four bytes following the PID_EXTENDED and length shall be a serialized UINT32 value "eMemberHeader" that is constructed by combining four 1-bit flags with by the 28-bit member ID. The flags occupy the 4 most significant bits of the UINT32 value. The flags are combined with the memberId as shown below:
FLAG_1 = 0x80000000
FLAG_2 = 0x40000000
FLAG_3 = 0x20000000
FLAG_4 = 0x10000000
eMemberHeader = FLAG_1 + FLAG_2 + FLAG_3 + FLAG_4 + memberId

This text does not specify the reserved bit for the "FLAG_MUST_UNDERSTAND" and also in the case this is used for RTPS Discovery, the mapping for the "FLAG_IMPL_EXTENSION".

For compatibility with existing deployed systems the specification should state that FLAG_1 is the FLAG_IMPL_EXTENSION and FLAG_2 is FLAG_MUST_UNDERSTAND.

*Add a note to 7.5.2.5 'MemberId' indicating the range of member IDs. *

In section 7.5.2.5 (MemberId) add a reference to 7.2.2.4.4.4.4.

The default value of an member defined with @optional is "not set".

However it is possible to also apply the @optional annotation. In this situation should the value specified in the @default override the "not set" default?

For example if MyStruct is specified as:

@mutable
struct myStruct {
  long m1;
  @optional @default(2) long m2;
}

Would the default value of m2 be "not set" or 2?

At first glance it would seem that @default should override since if that was not the desired behavior then the user could just as well omit it. On the other hand, there seems to be a bit of ambiguity. Imagine m2 is not set by the sender, would the receiver then get "not set" or 2. If it gets 2, then how would a user ever detect the lack of m2 being set which is one of the goals of optionality.

Do not allow a @default on an @optional member

The @optional annotation is incompatible with the @default annotation. When both are set it should cause an error or at least a warning that @default is ignored.

RTPS version 2.3 (see https://issues.omg.org/browse/DDSIRTP23-63) specifies that the alignment should be reset after the encapsulation header.

Consequently the serialization rules in 7.4.3.5.3 should be updated to include this.
Specifically in rule (1) after:

<< PUSH( MAXALIGN = MAXALIGN(<eversion>) )

We should add:

<< PUSH( ORIGIN=0 )

In section 7.4.3.5.3, rule (1) add alignment reset

Perform the change suggested in the issue description.

XTYPES should specify that if a type declares key members then derived types cannot add additional key members.

The reason is that the derived type will never be compatible with the base type according to the compatibility rules so there is no purpose on allowing that inheritance which would mislead the user.

Semantically it seems that extending the key breaks the substitution principle where a derived class can be used in place of a base-class anywhere. If we allowed key extension two different objects could appear to be the same when viewed as a "base class"

Additionally in section 7.3.1.2.1.1 'Member IDs' there is no mention of how inheritance impacts the automatic assignment of member IDs.

Specify rules for inheritance

The rules for inheritance could be added to a subsection following *7.2.2.4.4 'Aggregated Types'*. This new subsection should state that:

Structure types can inherit from other structure types as long as:

• The derived structure either has same extensibility kind or leaves the extensibility kind unspecified
• The derived type does not have a member with the same name or the same memberId as the base type or any of the ancestor types (i.e. recursively applying this rule to the parent)
• The derived type does define any key fields. Is this really what we want to do. Will it break some definition where the "base type" is just being reused as a "header"? All to think about it and come up with a preferred approach.

Also mention in 7.3.1.2.1.1 'Member IDs' that the memberId are continuing from the base class.

Section 7.2.2.4.4 'Aggregated Types' has a confusing organization of its sub-sections. It mixes at the same level description of common aspects of Aggregated types (e.g. members names, types, properties like being optional etc). With the classification of 'Aggregated Types' into "Structures' and 'Unions'.

Moreover the concept of "member index" is not explicitly defied even if it appears in the figures and UML model. The text does talk about a "declaration order" for members but does not tie it to the "member_index" concept.

It would be better if the subsections were reorganized. Rather than:

7.2.2.4.4.2 Structure Types
7.2.2.4.4.3 Union Types
7.2.2.4.4.4 Member IDs
7.2.2.4.4.5 Members That Must Be Understood by Consumers
7.2.2.4.4.6 Optional Members
7.2.2.4.4.7 Key Members

It would be better if it was:
7.2.2.4.4.1 General
7.2.2.4.4.2 Structure Types
7.2.2.4.4.3 Union Types
7.2.2.4.4.4 Members of an Aggregated Type
7.2.2.4.4.4.1 Member Name
7.2.2.4.4.4.2 Member Type
7.2.2.4.4.4.3 Member Index
7.2.2.4.4.4.4 Member ID
7.2.2.4.4.4.5 Must Understand Members
7.2.2.4.4.4.6 Optional Members
7.2.2.4.4.4.7 Key Members

This reorganization should be applied before other issue resolutions that affect the section as they would benefit from the more logical section numbering.

Reorganize section 7.2.2.4.4 as suggested in the issue description

Apply the suggested reorganization

Redefine the DHEADER used for Appendable and Mutable types to only contain the length of the serialized object that follows (O.ssize).

This affects the following parts of the specification:

• Table 39 ('Functions operating on objects and types'. The entry for DHEADER shall be changed to just say DHEADER(O) = O.ssize

• Section 7.4.3.4.1 'Delimiter Header (DHEADER)' remove mentions of the
  E_FLAG.

• Section 7.4.3.5.3 'Complete Serialization Rules'. Replace "DHEADER(O, <E>)" with "DHEADER(O)" this affects rules (9), (12), (15), (21), (27), (30).

Close because it duplicates DDSXTY-29

Duplicates DDSXTY-29

The first paragraph 7.3.1.2.1.10 (Default Literal for Enumeration) says:

Normally the default value for an object of a type is pre-defined based on the generic rules based on the characteristics of the type. For example, for an integer it would be the value zero and for an enumeration it is the literal with the lowest member ID.

This language is obsolete. In XTYPES 1.2 Enumerated types are not considered to have memberId. Only AggregatedTypes have memberIds.

Instead this paragraph should reference Table 9 (Table 9 – Default values for non-optional members). Which in the case of the enumeration says it is the first value in the enumeration.

In addition, Table 9 (Default values for non-optional members) on the row for Enumerations says the default is:

The first value in the enumeration.

This is a bit ambiguous. Most likely it should be interpreted as the first literal that appears in the enumeration. But the word "value" may be interpreted by some as meaning the "lowest value" of any literals in the enumeration. It shuld be reworded to avoid confusion.

Update Table 9 and section 7.3.1.2.1.10

Update the text as suggested in the issue description.

The compatibility rule for ENUM_TYPE Table 18 'Definition of the is-assignable-from relationship for bitmask and enumerated types' states:

• If extensibility is final the set of literals should be identical. Otherwise the two types should have at least one other literal (in addition to the default one) in common.

This will break types that were compatible in xtypes v1. Namely enumerated types that just had one literal in common.

Defining enumerations with a single literal which is then expanded is a common patten in a surprising number of applications. So this change is quite disruptive.

The proposal is to not require the minimum of two literals in common. In other words change the quoted paragraph to:

• If extensibility is final the set of literals should be identical.

In addition some people dislike the fact that we make enums that have different default values incompatible. This will make two enums like the ones shown below incompatible. There is a strong opinion that this will break a lot of existing systems:

enum Enum1 {
   @value(1) RED,
   @value(2) BLUE
};

enum Enum2 {
   @value(2) BLUE,
   @value(1) RED
};

enum Enum3 {
   @value(2) BLUE,
   @value(1) RED,
   @value(0) ORANGE
};

So the proposal is to also remove the requirement:

• The default literal has the same value.

Lastly there question/request to have the TypeEnforcementPolicy attribute ignore_member_names apply to Enum as well... Alternatively it could be a different policy attribute, e.g. ignore_enum_literal_names.
We have several customers that have this requirement.

Modify compatibility for enum types and non-final extensibility

Apply the changes suggested in the issue description.

The DDS-XTypes 1.2-beta1 document section 7.2.2.4.4.2 (Union Types) on page 34 first paragraph states:

> [...]
> (Note that it is not required for every potential discriminator value to be
> associated with a member.)

Supporting this, 7.4.3.5.1 (Notation used for the match criteria) on p.121 states:

> O : UNION_TYPE An object "O" of a Union type as defined in 7.2.2.4.4.2
> [...]
> * O.selected_member is the member of the union selected
> based on the value of the discriminator. Note that certain
> discriminator values may select no member.

However, 7.4.1.2.3 (Omission and Reordering of Members of Aggregated Types) on page 110 third para states:

> Because union members are identified based on a discriminator value,
> the value of the discriminator member must be serialized before the
> value of the current non-discriminator member.
> Neither member value may be omitted.

I suggest replacing "Neither member value may be omitted" by:

" The discriminator value may not be omitted.
If the discriminator value has an associated member then the member value may not be omitted. "

Section 7.5.2.11.6 (Operation: get_item_count) on page 185 states:

> The "item count" of the data depends on the type of the object.
> * If the object is of a union type, return the number of members in the
> object. This value will always be two: the discriminator and the current
> member corresponding to it.

I suggest replacing the last sentence by:

" This value will be two if the discriminator value has a corresponding member. It will be one if the discriminator value has no corresponding member. "

Modify the 7.4.1.2.3 description of union serializarion

Indicate that in the case of a union the only mandatory thing to serialize is the discriminator. The member may be omitted if no branch is selected.

XCDR serialization rules for strings and sequences serialize the length as an uint32 ahead of serializing each of the elements.

For short strings and sequences this can be a significant overhead. For example a 4 element sequence of octets would use 4 bytes for the sequence length and 4 bytes for the sequence content. That is 100% overhead. Worse since the serialized uint32 length must be serialized at a 4-byte offset, in some cases 3 additional padding bytes would be required. This would result on 7 bytes of overhead for 4 bytes of payload, or 175% overhead!!

It would be better is short sequences, that is those whose maximum length is less than 255 could be serialized using an uint8 length instead of a uint32. With this the overhead of the previous example would be 1 byte (or 25%).

An additional optimization would be to just serialize the string characters without the terminating NUL since this information is redundant with the length.

This encoding would affect type compatibility in that a "short" sequence would not be compatible with a longer one. This is different from the current situation where string/sequence length would not affect compatibility. With the new encoding short strings would be compatible with each other (regardless of their length) and likewise long strings would also be compatible with each other (regardless of length) as well as compatible with unbounded ones.

So therefore we would need an annotation to indicate we want to serialize it as a short string... Perhaps we could reuse @bit_bound. For example:

struct ShapeType {
    @bit_bound(8) string<32> color;
    long x;
    long y;
};

Disadvantage is that the only valid values when applied to strings/sequences would be @bit_bound(8) and @bit_bound(32).

Alternatively we could also a new annotation like @compact, @pack, @short, @small, ...

Defer until we can determine weather the optimization is worth the added complexity

The RTF thinks is is best to wait and see if the need for this kind of optimization is sufficient to justify the added complexity to the user, and the implementation

he concern is that this effectively introduces new sets of incompatible collection types:
"short" strings are now incompatible with regular strings
"short" sequences are incompatible with regular sequences,
and so on.

Note that two strings with a maximum length of say 20 would be incompatible if one is defined as a "sort" string and the other not. The one not defined as a "short" string would be compatible with (non-short) strings of any length. The one defined as short with short strings of any length.

This will increase the complexity to the user who must now decide whether their strings (and sequences) should be defined as short or not to save some bytes, but then live with the consequence that it will not be possible to extend them...

DDS-XTypes 1.2 section 7.2.2.4.3 (Collection Types) on page 30 bottom states:

> * Element type: The concrete type to which all elements conform. (Collection Elements
> that are of a subtype of the element type rather than the element type itself may be
> truncated when they are serialized into a Data Representation.)
> In the case of a map type, this attribute corresponds to the type of the value elements.
> Map types have an additional attribute, the key element type, that indicates the type of the
> may key objects.

I believe there is a typo in "type of the may key objects" - drop the word "may" ?

The paragraph continues:

> Implementers of this specification need only support key elements of
> signed and unsigned integer types and of narrow and wide string types; the behavior of
> maps with other key element types is undefined and may not be portable.

Is there a particular reason why enums were excluded from the supported key types?

Corrections were already applied in the formal document

The typo mentioned in the description was already corrected in the formal DDS-XTYPES 1.2 document.

Allowing enum to be used as key discriminator would introduce problems with type interoperability or data reception. Given that a similar behavior can be achieve at the application level (using the ordinal value associated with each enumeration literal) it seems better to leave the specification with the existing limitation.

Currently LC=6 indicates the length is multiplied by 2 and LC=7 indicates it should be multiplied by 4.

It would be better if LC=6 indicated the length is multiplied by 4 and LC=7 indicated it should be multiplied by 8.

The reason is that members of length 8 (INT64) and DOUBLE are far more common that members of length 2 (INT16 and CHAR16).

Change the interpretation of LC=6 and LC=7

Change de interpretation of the Length Code (LC) for values LC=6 and LC=7. The new interpretation shall be:

• LC = 6 = 0b110 indicates serialized member length is 4*NEXTINT
• LC = 7 = 0b111 indicates serialized member length is 8*NEXTINT

This impacts only de LC definitions that appear in section 7.4.3.4.2 'Member Header (EMHEADER), Length Code (LC) and NEXTINT'

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

In the RTPS spec the values of ReliabilityQosPolicyKind are defined to be:
BEST_EFFORT_RELIABILITY_QOS = 1
BEST_EFFORT_RELIABILITY_QOS = 2

However, in appendix D the ReliabilityQosPolicyKind is defined as:

enum ReliabilityQosPolicyKind {
    BEST_EFFORT_RELIABILITY_QOS,
    RELIABLE_RELIABILITY_QOS
};

To match what the RTPS specifies this should be modified to:

enum ReliabilityQosPolicyKind {
    @value(1)  BEST_EFFORT_RELIABILITY_QOS,
    @value(2)  RELIABLE_RELIABILITY_QOS
};

Duplicates DDSXTY13-9

Duplicates DDSXTY13-9

In Table 9 " Default values for non-optional members".

For type kind UNION_TYPE, the default value may require the discriminator to be set to the "lowest value associated with any member", however the "lowest" relation isn't defined for all possible discriminator types.
Boolean: use false (based on Table 9)
Byte: undefined (based on Table 3)
Char<N>: undefined
UInt<N>: well defined
Int<N>: need to define/clarify for negative numbers
Enum: treat as Int32 per Table 4

Modify the definition of the UNION_TYPE default value

In table 9 set the union according to these rules:

• Set the discriminator to the default value for the discriminator type
• If that discriminator value does not select a branch, then there is nothing else to set
• If that discriminator value selects a branch, then set the selected member to the default value for that corresponding member type

Note that even if there is no explicit "default" brach, it is still possible to set discriminator to a value they is not covered in the explicit cases. This selects the so-called "implicit" default which has an empty branch.

The RTPS Spec defines BEST_EFFORT and RELIABLE_RELIABILITY as:
#define BEST_EFFORT 1
#define RELIABLE 2 (as of RTPS2.4, previously it was defined as 3)

The XTypes Spec should align itself with these values by defining ReliabilityQosPolicyKind as follows in Annex D - DDS Built-in Topic Data Types:

enum ReliabilityQosPolicyKind {
    BEST_EFFORT_RELIABILITY_QOS = 1,
    RELIABLE_RELIABILITY_QOS = 2
};

Update the definition of enum ReliabilityQosPolicyKind in Annex D

Modify the definition of enum ReliabilityQosPolicyKind in Annex D to match what is shown below:

enum ReliabilityQosPolicyKind {
    @value(1) BEST_EFFORT_RELIABILITY_QOS,
    @value(2) RELIABLE_RELIABILITY_QOS 
};