The first sentence of page 215 says "As defined in the RTPS specification, a data encapsulation is identified by a two-byte value, the “encapsulation identifier” [RTPS].". But [RTPS] refers to DDSI-RTPS v2.3, which does not contain those terms. Those terms were last used in DDSI-RTPS v2.2. Instead, since v2.3 of DDSI-RTPS, we have a `SerializedPayload` instead of a "data encapsulation and a `RepresentationIdentifier` instead of an "encapsulation identifier". Furthermore, versions 2.3-2.5 (2.5 being the latest version at the time of this report) of DDSI-RTPS refer to DDS-XTypes v1.2 for the `RepresentationIdentifier`. DDS-XTypes v1.2 then refers to DDSI-RTPS v2.2. I haven't followed the chain further, but I think it should be broken in the next revision, with at least one of RTPS or XTypes ceasing to refer to the other.

In summary:

• DDS-XTypes v1.3 refers to something nonexistent in DDSI-RTPS v2.3.
• DDSI-RTPS v2.3+ refer to DDS-XTypes v1.2 on the same subject.
• DDS-XTypes v1.2 refers to DDSI-RTPS v2.2 on that subject.

The specification does not state clearly if a writer and and reader that have types with incompatible values of @unit or @range should match?

Also it is not clear as if both a complete TypeObject and a minimal TypeObject should be sent or just one and how it is decided.

It would seem like.a good idea to allow application (DataReaders) to opt in or out of matching writers that have types with incompatible @range and/or @unit. If so mechanisms should be provided to configure this and make sure the complete TypeIdentifier is propagated in those cases as the corresponding TypeObject is the only one that has the information of @range and @unit.

Annex B declares MinimalStructMemberSeq as:

// Member of an aggregate type
@extensibility(APPENDABLE) @nested
struct MinimalStructMember {
    CommonStructMember common;
    MinimalMemberDetail detail;
};
// Ordered by common.member_id
typedef sequence<MinimalStructMember> MinimalStructMemberSeq;

The comment is wrong: It contradicts section 7.3.4.5 where it says it should be ordered by member index. It is also inconsistent with struct CompleteStructMemberSeq before.

Instead, the comment before MinimalStructMemberSeq it should say:

// Ordered by the member_index

The `getTypeDependencies` operation (7.6.3.3.4.1) returns `TypeIdentifierWithSize`. The returned collection must use the SCCIdentifier for Strongly Connected Components. This begs the question, what is the size of the TypeObject corresponding to an SCCIdentifier?

Step (d) of the algorithm in 7.3.4.9.2 may imply that it is the serialized size of a sequence of TypeObjects of the components but there is nothing explicit.

Pg 48 7.2.2.4.6 first sentence

For each Aggergated Type "T" the type system defines a related [...]

-> Aggregated

Pg 48 7.2.2.4.6 first sentence

[...] obtainied from "T" by removing the key designation

-> obtained

Pg 50 7.2.2.4.7 first sentence

[...] obtainied from "T" as follows:

-> obtained

Pg 54 Figure 19 label at aggregation arrow to AnnotationParameter

+paramter_seq

-> +parameter_seq

Pg 133 Table 38 4th row column meaning

Conditionally swaps the bytes [...] matches the native Endianess

-> Endianness

Pg 146 continuation of 7.4.3.5.3 4th line from top

// FMMEBER can be NOPT_FMEMBER [...]

-> FMEMBER

Pg 215 Table 60 4th column, header

Endianess

-> Endianness

Pg 248 continuation of Annex A 2nd para from top

<xs:simpleType name="autoIdKind">
  <xs:restriction base="xs:string">
    <xs:enumeration value="hash"/>
      <xs:enumeration value="sequencial"/>

-> <xs:enumeration value="sequential"/>

Pg 263 continuation of Annex B bottom of page

// Flags that apply to type declarationa and DO affect assignability

-> declarations

Pg 266 continuation of Annex B 3rd para from top

// Used for Types that have cyclic depencencies with other types

-> dependencies

Pg 268 continuation of Annex B approx 10 lines down

// ============ Plain collectios - use TypeIdentifierKind =========

-> collections

The machine readable file machine readable file dds-xml_application_example.xml use some names that are not appropriate to the their context. For example it has a <data_reader> that has been named "MySquareWriter" this is likely a copy-paste error and should have been named "MySquareReader"

The spec states that @key members are always "must understand" does this mean that when represented in a TypeObject the member should also have the "must understand" flag set or is it enough with it being marked with the "key" flag as this would already imply its must understand nature?

Either way it should not impact assignability but it would impact the TypeId computation.

The type assignability rules for Enumerated Types require knowledge of whether the literal names should be considered for assignability.

Right now this can only be configured when the type is declared using the @ignore_literal_names annotation. However in some cases it may be necessary to change this behavior at run-time for a particular DataReader.

To support this use-case it would be helpful to add a ignore_enum_literal_names field to the TypeConsistencyEnforcement QosPolicy

When an annotation application definition has a simpgle paramater the application can omit the paramater name.

When an annotation application specifies multiple parameters it is possible to commit the parameter name for the parameter named "value" ,

This means that an annotation that was specified with a single parameter (not called value) which is then extended will need to be modified if a second paramater is added.

Instead it would be more flexible to say that the first paramater can be unnamed regardless of the name.

There are three problems.

1. The beginning of 7.3.1.2.1.11 says “Table 18. In some cases, this is not desirable. This default behavior may be modified using the @ignore_literal_names annotation.” It is unclear what exactly may not be desirable. Perhaps this was referring to the fact that enumerator names are used in the assignability check which indeed may be undesirable.

2. There is no way for `@ignore_literal_names` to be encoded in TypeObjects which means they are not used during discovery and cannot be used in assignability checks.

3. The text should clarify if this is an annotation that is only applied locally and/or applied to remotes.

Would be useful to have support for @optional for union members. As IDL exceptions can be used through DDS-RPC also add exception members to this table, very likely to the ones that also are supported by structures

In the spec this section reads:

7.2.1.1 Type Evolution Example

Assume a DDS-based distributed application has been developed that uses the Topic “Vehicle
Location” of type VehicleLocationType. The type VehiclePositionType itself was defined
using the following IDL:

(quote)
// Initial Version
struct VehicleLocationType {
(quote)

VehiclePositionType in the second sentence should be replaced with VehicleLocationType

The specification is not consistent regarding which elements can be annotated. Specifically regarding typedef declartions.

Section 7.2.2.6 "Annotations" says:
"An annotation describes a piece of metadata attached to a type or an element/member/literal of an aggregated/collection/enumerated type. Annotations can also be attached to the related_type of an alias type."

However
section 7.3.1.2.1 (Built-in Annotations) says:

In IDL, an annotation may be applied to any construct or sub-construct
(see Sub Clause 7.4.15.2, [IDL]). This specification restricts the applicability of annotations to constructed types, bitmask constants, enumerated type literals, and members of aggregated types.

I believe the intent all along was to allow annotations, such as @range and @unit in typedef. Also would be nice to align with whet IDL4 says.

At a minimum in XTYPES we should remove the specification of where annotations apply from section 7.3.1.2.1 and instead reference 7.2.2.6.

Pg 43 7.2.2.4.4.4.3 Member Index 2nd sentence

[...] of the member within the Aggegated type.

Pg 47 7.2.2.4.5 Inheritance of Aggregated Types 1st sentence

The Type System supports single inheritance of Aggegated Types.

Pg 49 continuation of 7.2.2.4.6 comment before union Command_TypeErased

// The related KeyErased type definition only applies to aggegated types.

Pg 51 continuation of 7.2.2.4.7 comment before union Command__KeyHolder

// The related KeyHolder type definition only applies to aggegated types.

On this last occurrence, is the double underscore in union Command__KeyHolder intentional?

The Resolution Summary of DDSXTY13-23 states:

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

• [...]
• The derived type does not 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"?

I propose to change the first sentence to

• The derived type does not define any key fields if any of its ancestor types is non nested.

This restores viability for the mentioned use case where the base type(s) are just being used as header(s).
It hinges on the assumption that if all base types are nested then the question of assignability does not arise at the topic level.

This is related to https://issues.omg.org/issues/DDSXTY14-13, and it might actually be covered by it, but I can't read into the comments at the moment to see if this specific issue was mentioned. As mentioned in 7.2.2.2.1, strings should be either UTF-8 or UTF-16. @try_construct(TRIM) can cause strings to be truncated. If they are truncated in the middle of a UTF-8 multi-byte code point or UTF-16 surrogate pair, then it would leave invalid data at the end of the string. Ideally an implementation could read trim the strings intelligently, but the spec should say what the behavior is.

As defined create_sample can only return the sample object. This doesn't allow the API to indicate that there was an error unlike other calls in DDS. Other operations either can't normally fail, return an interface that can be null, or return a ReturnCode_t. At least in the C++ Language Mapping, create_sample can return a struct or a union by value, so it can't be null in those cases (section 5.11). I imagine this might be different in other mappings though.

Note: This issue was filed in RTF 3 by Idar Carlsen. As RTF3 is already close it is being copied into RTF4.

// 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)).

Note: This issue was filed by Sam Nosenzo in RTF 3. As the RTF 3 is already close it has been copied to RTF4

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.

// 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)).

When serializing a sequences of non-primitive elements, the XTYPES spec requires serializing a DHEADER ahead of serializing the number of elements and each element. This is rule (12)

Arrays of non-primitive elements also serializing the DHEADER but not the number of elements. This is rule (9)

I think it would make sense to modify or at least relax these rules.
At a minimum arrays and sequeces of enumerated types and bitmask types should not have a DHEADER as it does not add information beyond what is available knowing the number of elements and size of each element. That it, they should behave as primitives (basically they are integers).

Additionally it may be better to not have the DHEADER at all for sequences and arrays. Or at least for sequences or arrays whose elements are final.

Basically the "extensibility" of the sequence is already handled by having the number of elements and having a DHEADER adds nothing and makes types that contain sequences of FINAL incompatible with XCDR1. This is a side-effect that we did not want or anticipate. Otherwise types that are constructed from only FINAL types would be compatible between XCDR1 and XCDR2 (except for 8-byte aligned types).

This issue was raised by Idar Carlsen (Kongsberg Defence & Aerospace)

In the X-Types 1.3 specification, under the “7.4.3.5.3 Complete Serialization Rules” section, it says that non-trivial maps should have a DHEADER when XCDR2 is used (rule 15). Notably, it only has the DHEADER – unlike the version 1 encoding, the size (in terms of numbers of entries) of the map is not serialized. This differs from how sequences are serialized, as they include the size as well. Is this correct, or should the size of the map also be serialized in addition to the DHEADER?

It seems to me that some of the other DDS implementations include the size, even though the specification does not say so.

Sections are:

7.3.1.9 Map Types
Map types as described in this specification are fully compatible with the IDL constructs of the
same name defined in the Extended Data-Types Building Block of [IDL].
Structures as defined by this specification are fully compatible with the IDL constructs of the
same name.
7.3.1.10 Structure Types
Structures as described in this specification are fully compatible with the IDL constructs of the
same name.

"Structures as defined by..." is duplicated twice.

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 union TypeIdentifier definitoon in Annex B contain several cases commended out. This is done because (per the comment in the IDL) union cases all have to have an associated member/value

// All primitive types fall here.
// Commented-out because Unions cannot have cases with no member.
/*
case TK_NONE:
case TK_BOOLEAN:
case TK_BYTE_TYPE:
case TK_INT8_TYPE:
case TK_INT16_TYPE:
...

Since the union discriminator is an octet, it is possible to set it to the values shown in the comment (e.g. TK_INT8_TYPE) in this situation since the case member is not shown the discriminator will be set but no branch would be selected so there is no associated value.
In other words, we can get the desired behavior of having the discriminator set but no value selected (so nothing beyond the discriminator is serialized), but we cannot express the expectation of all those cases in the IDL...

This could be corrected in two ways:
(1) We could use a enumerated value with @bit_bound(8) as the type of the discriminator instead of the octet. The list of literals would make it obvious what the expected values for the discriminator
(2) We could keep the union discriminated by an octet and uncomment all the cases for the primitive types. Then we would need to add a "dummy" member so the case has an associated value, but we could mark it @non_serialized so it has no impact on the wire representation.

It would seem that (1) is cleaner but (2) is less disruptive...

It's not clear how a user of a DynamicData object that represents a union gets the discriminator value. We derive the following:

// see pgh 1 of 7.2.2.4.4.3 for use of "discriminator" as a magic string
const MemberId id_disc = dyndata->get_member_id_by_name("discriminator"); 
if (id_disc == MEMBER_ID_INVALID) { some error happened }
// based on union_type_descriptor.discriminator_type->get_kind(), determine the type of the discriminator
// in this example, let's say it's an IDL long
int val;
dyndata->get_int32_value(val, id_disc);

It would be better for the spec to have a clearly defined way of getting a MemberId that represents the discriminator. It could be a new API in DynamicType or TypeDescriptor.

RTPS 2.3 section 9.4.5.3.1
"D=0 and K=1 means that the serializedPayload SubmessageElement contains the serialized Key."

XTypes section 7.4 "Data Representation" should define the rules for encoding an object of a type defined by the 7.2 "Type System" to a Key-only serialization.

Using what's currently in the spec, there are two potential interpretations:

a. follow all the encoding rules as for a full object (adding DHeader, EMHeader, etc.) but any part of that object that's not a key gets skipped, using 7.2.2.4.7 to determine what's a key

b. use the rules in 7.6.8 (which are explicitly only for a KeyHash) to get a KeyHolder object and then encode that

Both figures have get_member_id_by_index methods instead of get_member_id_at_index like the rest of the spec does.

Section 7.3.4.5 specifies that all struct and union members in TypeObjects are to be ordered by member index/declaration order.

•The elements in CompleteStructMemberSeq shall be ordered in increasing values of the member_index.
•The elements in MinimalStructMemberSeq shall be ordered in increasing values of the member_index.
•The elements in CompleteUnionMember shall be ordered in increasing values of the member_index.
•The elements in MinimalUnionMember shall be ordered in increasing values of the member_index.

There are comments in the IDL in front of the sequence typedefs for these members that also specify the order. The complete ones agree that they should be sorted by member index, but the minimal ones say they should be sorted by member id:

// Ordered by common.member_id
typedef sequence<MinimalStructMember> MinimalStructMemberSeq;
...
// Ordered by MinimalUnionMember.common.member_id
typedef sequence<MinimalUnionMember> MinimalUnionMemberSeq;

Typo, it says

@posiiton(2) XCDR2

but should say

@position(2) XCDR2

The encoding of the TypeInformation member in the builtin topics should be explicitly specified. There is a normative comment on using XCDR2 for v1.3 types in the IDL, but this can be interpreted not to apply in the context of the builtin topics which are otherwise XCDR1.

Section 7.6.3.3.4 states the following sentence on how to encode the Participant GUID into the dds::rpc::RequestHeader:

The Service instanceName that appears in the dds::rpc::RequestHeader shall be set to the string obtained by concatenating the prefix “dds.builtin.TOS .” With the 16-character string version of the DomainParticipant GUID encoded using hexadecimal digits with lower case letters. There shall be no “0x” ahead of the hexadecimal digits. For example, “dds.builtin.TOS.123456789abcdf0”

This seems to imply that you need to encode the Participant GUID as a 16 digit hexadedecimal string, which wouldn't allow you to represent the entire GUID. Probably the 16 bytes do no intend to refer to the hexadecimal digits of the string representation, but rather to the 16 bytes of the GUID itself. A couple of paragraphs further down it refers to the DDS-RPC spec, where indeed the 16 byte restriction is not mentioned:

The dds::rpc::RequestHeader in the TypeLookup_Request and the TypeLookup_Reply shall be set as specified in the [DDS-RPC] specification.

The XTypes spec seems to suggest that @must_understand fields are applicable to any non-final datatype. Section 7.3.1.2.1.9 mentions this:

"By default, the assignment from an object of type T2 into an object of type T1 where T1 and T2 are non-final types will ignore any members in T2 that are not present in T1. This behavior may be changed by applying the @must_understand annotation to a member within a type definition."

That would mean that @must_understand fields are also applicable to @appendable structs, but in this case there is no way for a field to be identified as must_understand field in its Delimited-CDR representation.

Of course you could state that in case of @appendable structs, you should determine assignability at discovery time and not at run time, in which case you are not dependent on the availability of a must_understand bit in the serialized blob. However, in case a Writer publishes a sample with a field that is both @must_understand AND @optional, according Table 19 (section 7.2.4.4.8) there is no mismatch between this Writer and a Reader that is missing the field (that is only the case if the field has @optional set to FALSE), which means the sample needs to be matched at runtime.

The spec is a little unclear of the semantics in this case: I guess that if the optional value is empty but must_understand you can slice it out of the projected type, but when it is not empty you are not allowed to slice the value out since it is a must_understand value and you will have to discard the whole sample instead. It would be nice if the spec could explicitly confirm or deny this.

But working from the presumption that you are indeed allowed to slice out values that are both empty and must_understand, the next problem arises immediately: how does a Reader know that a sample containing an unfamiliar field actually represents an optional field that is must_understand?

Let's consider a scenario where I have a Reader that is reading a type A with the following defintion:

@appendable struct A {
    @key long id;
     long x;
};

Now this Reader can be matched against all sorts of Writers, including Writers that have appended all kinds of fields to the end of this datatype: its deserializer simply slices everything out that comes after field x.

This works well for most appended versions of this datatype, but now suddenly an additional Writer joins the system with the following definition:

@appendable struct A {
    @key long id;
     long x;
    @optional @must_understand long y;
};

This Writer will match the Reader according to Table 19 since although the @must_understand annotation is TRUE, the corresponding @optional field is NOT false. So now the deserializer for our Reader has to deserialize a sample for which it doesn't know what the payload after the x actually represents. It might represent a value that it can safely slice out, or it might represent a value that may not be sliced out.

The spec states in rule number 20 of section 7.4.3.5.3 that in case of XCDRV2, an optional member is preceeded by a boolean called is_present. The problem here is that our deserializer doesn't know where the sample originates from therefore has no knowledge whether the byte following field x represent an is_present boolean or just some other sliceable field.

So the basic question boils down to this:

• Do we allow fields that are both must_understand and optional in case of Appendable extensibility?
• If so, how do we indicate in this case that a field is both optional and must_understand in a preferably backward compatible way?

Figure 16 defines bitset as another kind of aggregated type. One might assume that this has the semantics of an IDL4 bitset.

The text after Figure 16 and the rest of the spec doesn't define how bitset works in the type system (assignability), type representation, and data representation.

DynamicTypeSupport has the following IDL definition in Annex C:

interface DynamicTypeSupport : TypeSupport {
  /* This interface shall instantiate the type FooTypeSupport
   * defined by the DDS specification where "Foo" is DynamicData.
   */
  /*static*/ DynamicTypeSupport create_type_support(
    in DynamicType type);
  /*static*/ DDS::ReturnCode_t delete_type_support(
    in DynamicTypeSupport type_support);
  DDS::ReturnCode_t register_type(
    in DDS::DomainParticipant participant,
    in ObjectName type_name);
  ObjectName get_type_name();
};

This definition can't be used in an XTypes implementation, at least in one using standard IDL. register_type and get_type_name can't use those names because a derived interface can't define operations that share names with ones in its base interfaces. This is described at the end of 7.4.3.4.3.2.1 in IDL 4.2. Another issue is the "static" operations. They get the point across as to what the author means but, they are also not usable as IDL can't define operations as static. DynamicTypeBuilderFactory and DynamicDataFactory also do this.

Add BITMASK_TYPE to table 9

Since "Core Data Types (Sub Clause 7.4.1 [IDL])" is included in the XTypes type system model, it needs to include "fixed"

TypeObject assumes that all union case labels are representable in a 32-bit integer:

// Case labels that apply to a member of a union type
// Ordered by their values
typedef sequence<long> UnionCaseLabelSeq;

Both IDL 4.2 and the general type system in XTypes (Figure 18, 7.2.2.4.4.3) allow 64-bit integer types as discriminators and therefore 64-bit values as case labels.

Section 7.3.4.9.2 describes the algorithm for computing type identifiers for strongly connected components. Step 4b says

If the Strongly Connected Component (SCC) has multiple types, then sort them using the lexicographic order of their fully qualified type name. Let SCCIndex(U) be the sort index of each type U belonging to the SCC starting with index 1 for the first type. For anonymous types concatenate the fully qualified name of the containing type with the member name using “.” as the separator, for example “MyModule::MyStruct.myMember”.

This does not cover all possibilities for anonymous types. To illustrate, the following IDL with recursive types uses an anonymous type in a typedef:

struct NodeData {
  long l_data;
};
struct TreeNode;
typedef sequence<@external TreeNode> Children;
struct TreeNode {
  NodeData data;
  Children children;
};

The algorithm requires a name for sequence<@external TreeNode>. In general, the rule for naming anonymous types in step 4b must be expanded to include anywhere an anonymous type may appear including structs, unions, typedefs, and other anonymous types.

An additional, related, problem is that given the definition of Plain...
7.3.4.1 “Plain types only have a TypeIdentifier. Non-plain types have both a TypeIdentifier and a TypeObject.”
the children field of TreeNode of the SCC example in 7.3.4.8 is a Plain Collection and has no TypeObject

struct NodeData {
  long l_data;
};
struct TreeNode {
  NodeData data;
  sequence<@external TreeNode> children;
};

Step 4(b)ii of the algorithm in 7.3.4.9.2 requires that all of the types in an SCC have a TypeObject 4(b)ii.
Possible Solutions and Notes:
The algorithm implies that all of the types involved in a Strongly Connected Component have a type identifier of TI_STRONGLY_CONNECTED_COMPONENT. The precludes the use of the Plain Collections in Strongly Connected Components. Thus, if the algorithm of 7.3.4.9.2 is not revised, then the definition of Plain Collections needs to be revised to exclude those involved in a Strongly-Connected Component.

Enum and bitmask can have extensibility

    typedef TypeFlag   EnumTypeFlag;        // Unused. No flags apply
    typedef TypeFlag   BitmaskTypeFlag;     // Unused. No flags apply

Definition of equality is based on the "Properties" of the class as defined by the UML models (for example, Table 54). However, associations/aggregations (which are not properties) are just as important for equality. An example is the TypeDescriptor that's associated with each DynamicType. While not a Property, the state of TypeDescriptor is effectively part of the state of DynamicType.

A related issue is that DynamicTypeMembers can only be equal "if they belong to the same type." This seems to be both unnecessary and prevents certain valid use cases. An application may want to determine if two different structs each have a string member of a certain name. Based on the Type System model (sect 7.2) it would be natural to apply the equals() operation on the members to check their logical equality independent of which struct they're declared in.

The IDL defined in Annex C uses the type BoundSeq as a member of TypeDescriptor, but BoundSeq is not defined in the spec.

Larga data types or types that contain compressible data (e.g. strings) can benefit from using compression at serialization time.
This would reduce the size required to store the data in the reader/writer caches as well as the bandwidth used to send the data.

This is complementary to transport-level compression and has the advanatage that the data is only compressed once (at serialization, instead of every time it is sent) as well as reducing memory requirements.

7.4.1.2.1 7th paragraph (maybe) / 3rd paragraph of page 126: : “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.”

It seems like the second “by” should be removed.

IDL4 defines @default as a way to specify a custom default value for an IDL element, but DDS XTypes defines it own default mechanism, shouldn't the value of @default be used when set?

https://issues.omg.org/browse/DDSXTY13-7 added these two constants and they were placed in the IDL that appears in Annex B. However they were left out of the separate machine readable file https://www.omg.org/spec/DDS-XTypes/20190301/dds-xtypes_typeobject.idl

In addition, the comment:

    //   - COMMON indicates the TypeIdentifier identifies equivalent types
    //     according to both the MINIMAL and the COMMON equivalence relation.
    //     This means the TypeIdentifier is the same for both relationships

Should say (replace second "COMMON" with "COMPLETE"):

    //   - COMMON indicates the TypeIdentifier identifies equivalent types
    //     according to both the MINIMAL and the COMPLETE equivalence relation.
    //     This means the TypeIdentifier is the same for both relationships

The specification should state the behavior if a derived type extensibility kind is specified to be different from that of its parent.

Furthermore for usability we should specify the behavior if the derived type does not specify any extensibility kind. Does it 'inherit' that of the parent or is it assumed to be the 'default'.

Current thinking: It is an error to have a derived structure specify a different extensibility kind than its parent. Leaving it unspecified sets the derived type extensibility type to that of your parent.

Basically the serialization of the derived class does not add its own header.

There are inconsistencies in the two definitions of the RTPS Encapsulation Header I've found so far. The major issue is that the values for the encoding identifiers are different between 7.4.3.4 and 7.6.3.1.2 for non-XCDR1 encodings. These are the big-endian values compared:

The other issue is that while 7.6.3.1.2 describes the two options bytes of the encapsulation header that follow the encoding identifier and extends it for padding info, 7.4.3. is lacking in details as far as I can see. The serialization rules has them in 7.4.3.5.3 as `OPTIONS`, but doesn't define it in any of the tables before the rules like all the other symbols are. It does mention encapsulation in 7.4.3.5, but doesn't mention anything about extending the options bytes.

The range/min/max group of standard IDL annotations are not referenced in table 21 and its surrounding sections.

It would seem like the try_construct behavior could be applied to range/min/max when the publisher and subscriber have different but compatible annotations.

DDSXTypes refers in section 3 to IDL4.2 but still duplicates a lot of things which are now part in IDL4. It is now very hard to determine what is part of IDL4 and what is DDSXTypes specific, for example bit_bound seems to be just for DDS, it is not part of IDL4.

In 7.2.1 it says:

Integral types of various bit lengths (16, 32, 64), both signed and unsigned

8 bit types are missing, so updated this to

Integral types of various bit lengths (8, 16, 32, 64), both signed and unsigned

TypeLookup IDL in 7.6.3.3.3 contains the following unsigned long constants in IDL:

// computed from @hashid("getTypes")
const unsigned long TypeLookup_getTypes_HashId = 0x018252d3;
// computed from @hashid("getDependencies");
const unsigned long TypeLookup_getDependencies_HashId = 0x05aafb31;

However later in the IDL two unions called TypeLookup_Call and TypeLookup_Return which use those constants as branches are discriminated with a long. Since long is apparently specified by the RPC spec, then the type of the constants should be changed to long to match the unions.

Other issues in this IDL:

• TypeLookup_getTypes_Result and TypeLookup_getTypeDependencies_Result both use DDS_RETCODE_OK as an IDL constant. It should be DDS::RETCODE_OK (from the DDS core spec 2.3.3)

• TypeLookup_Call and TypeLookup_Return both use IDL constants that end in the word "Hash" but should match the ones above (they are missing "Id")

• TypeLookup_Reply contains a member of type RequestHeader which should be ReplyHeader

AnnotationParameterValue has a members for integer types. uint_16_value is the only one that has an underscore between the int and the size and this appears to be a typo. Given that it seems that the name has no real bearing in this situation, it should be fixed by changing uint_16_value to uint16_value.

The text reads:

"A type's key can only include members of the following types: primitive, aggregation,
enumeration, bitmask, array, and sequence."

It should include 'string' and 'wstring'.

In this table, the row second from the bottom for "XCDR MUTABLE 2 Little Endian" has the wrong identifier.

In section 7.6.8 it is stated that for a nested struct that is annotated as key for an embedding struct, you have to follow the following process to to generate its KeyHolder: "If there are any key members, then remove the non-key members from FooKeyHolder. Otherwise do not remove any members."

So what if the struct has no explicit key members, but it has explicitly mentioned that a certain field should not act as key? Take for example the following example:

struct Foo {
    long x;
    @key(false) long y;
};

struct Bar {
    @key Foo myFoo;
    string name;
};

There are three different ways to interpret the rules for this usecase:

1. Both x and y will end up in the KeyHolder, since Foo did not specify any key members, so nothing gets removed.
2. Only y will end up in the KeyHolder, since Foo specified explicitly that x should not act as key.
3. Neither x nor y will end up in the KeyHolder, since some of the members have an explicit key annotation and so I remove all the members which are not keys, which is y (stated explicitly) and x (stated implicitly).

So the big underlying question is: is explicitly stating @key(false) equal to not having a @key annotation at all, or does explicitly stating that a member is not a key have some more expressive power over implicitly determining its key status by absence of the @key annotation?

The paragraph that explains ignore_member_names defines its semantics as follows:

• If the option is set to TRUE, member names are considered
• If the option is set to FALSE (the default), then
  member names are not ignored

The mode of "considering" would seem to be the same as "not ignoring." Thus the spec is currently stating that the two options are equivalent. Since the name is ignore_member_names, that indicates that setting TRUE should indeed ignore them.

The spec should be changed to indicate that if the option is set to TRUE then member names are ignored.

It is possible to put an annotation on an attribute with multiple declarators, like this:

struct Foo {
  @key long x, y;
};

What is the effect of this? Does the annotation apply to both declarators? In that case, how do you interpret the following:

struct Foo {
  @fieldid(0x01000) long x, y;
};

The row for ENUM_TYPE in Table 40 defines an enum's holder type.

Footnote 3 on page 63 indicates that the type system is designed to allow a DataReader to consume a byte stream from a differently-typed (but assignable) DataWriter without "requiring the consultation of per-DataWriter type definitions during sample deserialization".

The current definition of Enum Assignability fails in this respect. It needs to prevent enum types from being assignable when their holder types differ.

Also relevant - pgh 2 of 7.2.4.2 "...Enumerated types (Enumeration and Bitmask) are delimited types as their serialized size is fixed"

Arrays of all kinds/extensibilities are covered by rules 8-10. Following those we find the "comments" below:

// Arrays with extensibility APPENDABLE use common APPENDABLE rules:
// (29)-(30)
// Arrays with extensibility MUTABLE are not allowed. Treated as APPENDABLE.

Which is either redundant or contradictory. Same issue with Sequences (rules 11-13) and maps (rules 14-16).

Due to this, the notes before rules 29-30 should be revised to remove "Collection or"

// Extensibility APPENDABLE (Collection or Aggregated types), version ?
// encoding

7.6.3.1.1 ends with
"The default value of the DataRepresentationQosPolicy shall be an empty list of preferences.
An empty list of preferences shall be taken to be equivalent to a list containing the single element XCDR"

This contradicts the rest of the section which describes how XCDR (v1) is optional. The default should be XCDR2.

7.6.3.3.3 defines built-in RTPS Endpoints for TypeLookup, but doesn't specify their Data Representation. Since TypeLookup is new, this should be XCDR2.

In section 7.6.2.3, that introduces the TypeLookupService, the datatypes used for exchanging TypeLookupRequests and TypeLookupResponse are introduced, and so are the endpoints used to exchange them.
However, what is missing is the topic names used for the topics carrying these requests and their responses. Technically you might not need the topic names to build an interoperable implementation, because the endpoints are builtin endpoints and therefore don't need to be matched, but nevertheless, the topic will need to have a name and the name might as well be part of the spec.

Rule 23 is missing "ALIGN(4)" before PID_SENTINEL

// Structures with extensibility MUTABLE, version 1 encoding
(23) XCDR[1] << {O : MSTRUCT_TYPE} =
XCDR
<< { O.member[i] : MMEMBER }*
<< { PID_SENTINEL : UInt16 }
<< { length = 0 : UInt16 }

Section 7.3.2.5.1 'Structures' states:

Structures contain four kinds of declarations:
• Applied annotations
• Verbatim text
• Members
• Constants

However section 7.3.1.10 'Structure Types' states:

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

IDL (4.3) does not allow constant declarations inside structures. So these two statements are incompatible.

Also the UML model in 7.2.2.4.4.2 'Structure Types' states structures contain only members. And constant declarations are not members.

Therefore it seems like the text in Section 7.3.2.5.1 should be modified to remove the bullet about constants.

In this section there is a bullet stating:

• A type may be FINAL, indicating that the range of its possible data values is strictly defined. In particular, it is not possible to add elements to members of collection or aggregated types while maintaining type assignability.

This is confusing. What does it mean that " the range of its possible data values is strictly defined"?
Moreover, it talks about collection types where Table 12 says that for these types the extensibility kind has no effect.

It sis recommended that this bullet is rephrased to just say that members cannot be added, removed or reordered.

1. In 7.6.8, the algorithm for creating a KeyHolder states that:

If there are any key members, then remove the non-key members from FooKeyHolder. Otherwise do not remove any members.

This seems to say that if there are no fields marked as keys, leave all of them open to be able to be used as keys. That would be consistent with implied key behavior.

2. There is an example of implied @key in Annex D, where the TopicData types specify BuiltinTopicKey_t as a key, but the single member of BuiltinTopicKey_t is not marked as a key.

3. At the same time 7.2.2.4.4.4.8 says:

If a given type has no members designated as key members, then the type—and any DDS Topic that is constructed using it as its type it—has no key.

It also says that:

In the event that the type K of a key member of a given type T itself defines key members, only the key of K, and not any other of its members, shall be considered part of the key of T.

This doesn't go against implied keys, but would be a good place to mention them in addition to the previous sentence.

4. 7.3.1.2.1.3 says that:

To declare a member as part of the key, users shall apply the @key annotation...

7.2.2.4.4.4.8 and 7.3.1.2.1.3 seem to have been written under the assumption that @keys can't be implied. If the specification actually requires this, which it appears that it does given Annex D, then it should say so in those two sections.

Finally, a couple thoughts/questions came up about implied keys behavior since it is not defined in the spec:

1. Given a situation like:

@nested(TRUE)
struct A

;

@nested(FALSE)
struct B

;

Shouldn’t a2 be the only element of the key of B, because we’re explicitly saying a1 isn’t part of the key?

2. Should implied key behavior (potentially including the behavior in the previous point) apply to union discriminators? For example:

@nested(TRUE)
union TestUnion switch (long)

;

@nested(TRUE)
union KeyedFalseTestUnion switch (@key(FALSE) long)

;

@nested(TRUE)
struct A

;

@nested(FALSE)
struct B

;

This section should have an explanation or cross-reference to describe what <OPTIONS> is (used in 1st encoding rule in the section)

In section 7.2.2.2.1.2.4 String<Char8> type
The specification does not provide a description of the "length" and "bound" values shown in Figure 9.

In the case of strings, specially String8, there is an ambiguity on whether the "bound" and "length" represent the number of characters, or the number of bytes in the UTF-8 encoding mentioned in 7.2.2.2.1.2.4, or something else.

an interpretation of the length of the string.

7.3.1.2.1.7 Nested Types

By default, aggregated types and aliases to aggregated types defined in IDL are not considered to be nested types.

...

If not present on a module, the value defaults to that of the enclosing module. If a top -level module is not annotated, the default is FALSE.

...

In addition to the above annotations, IDL compilers shall provide the means to change the default value for non-annotated top-level modules.

Given the fourth sentence, the first and third sentences should also say the nested status of a non-annotated type is implementation defined.

In 7.6.8 'Interoperability of Keyed Topics' it states:

As described in [RTPS] Clause 9.6.3.8, “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 as described below.

It is not clear whether the intent is that this modification impacts only implementors of the DDS-XTYPES or whether it is intended as a change in RTPS (which would require an issue filed on the DDSI-RTPS specification).

The IDL declaration of interface DynamicDataFactory in Annex C, declares the operation with no arguments.

However according to section 7.5.2.10 'DynamicDataFactory' the operation takes a parameter of type DynamicType. Therefore the correct IDL declaration should have been:

        DynamicData create_data(in DynamicType);

In DDS-XTYPES 1.3 there was an issue (https://issues.omg.org/browse/DDSXTY13-2) whose resolution added the precise specification of the computation of the memberId. This is now in section 7.3.1.2.1.1 'Member IDs' specifically the three-step algorithm towards the end of the section.

This algorithm fully uses 32 bits. The 4 MSB are set to zero and the remaining 28 bits computed from a hash. Because of this there is no longer a 'reserved range' for memberIds.

However the resolution of DDSXTY13-2 still left some text in section 7.2.2.4.4.4.4 that talks about reserved ranges. This text should also have been removed. In fact it seems that there was an instruction in DDSXTY13-2 to remove the paragraph but it either was not applied correctly or it missed a sentence that followed the paragraph. To correct it, the following text should be removed from section 7.2.2.4.4.4.4 'Member IDs'

The remaining part of the member ID range—from 0 to 268,402,687 (0x0FFFBFFF)—is available for use by application-defined types compliant with this specification.

The CLIENT_Representation contains an extra field client_timestamp that is not in the IDL defined in Annex A.

The AGENT_Representation contains an extra field agent_timestamp that is not in the IDL defined in Annex A.

DDS-XML defines the XML data representation. See 7.2 of DDS-XML
DDS-XML defines the XML type representation. See 7.3.3 of DDS-XML

So these definitions could be removed from DDS-XTYPES and just reference those specs.

Also the XSD type representation could be deprecated from DDS-XTYPES. This has not been popular in practice. The XML type representation is far more popular...

Section 7.6.3.1.3 'DataRepresentationQosPolicy: Platform-Specific API' states:

The topic, publication, and subscription built-in topic data types shall each indicate the data representation of the associated entity with a new member:

@id(0x0073) DDS::DataRepresentationQosPolicy representation;

This does not follow the naming conventions for field names. Instead it should have said that the new member should be:
@id(0x0073) DDS::DataRepresentationQosPolicy data_representation;

Likewise in Annex D the declarations of structures TopicBuiltinTopicData, TopicQos, PublicationBuiltinTopicData, DataWriterQos, SubscriptionBuiltinTopicData, and DataReaderQos all have the member:

@id(0x0073) DDS::DataRepresentationQosPolicy representation;

This should be changed so the member is:

@id(0x0073) DDS::DataRepresentationQosPolicy data_representation;

Section 7.2.2.1 'Namespaces' states:

Modules are namespaces whose contained named elements are types. The concatenation of module names with the name of a type inside of those modules is referred to as the type’s “fully qualified name.”

This is not enough to fully determine the fully qualified name. How is the "concatenation" done? What character is used to separate the successive module names?

For example what should be the fully-qualified name of the type described in in the following IDL?

module A {
module B {
  struct Foo {
    ...
  };
};
};

Assuming "::" is used to separate namespaces it would be "A::B::Foo"

The issue of type names is a bit broader. Currently it is not so clear that every type has a name. Is that really so? What about anonymous types defined within a structure?

The definition of MemberDescriptor (7.5.2.7) which is used to describe members of a Structure seems to imply every type must have a name. This is because each MemberDescriptor has an associated DynamicType (7.5.2.7.10 'Property: type') which according to 7.5.2.7.10 it cannot be null. And the DynamicType::get_name() should return the name of the type.

On the other hand Figure 5 seems to indicate only Modules and ConstructedTypes (according to Fig 5 these are: Alias, AggregateTypes, EnumeratedType, Collection) have a "ScopedIdentifier" which is their name.

This would mean that PrimitiveTypes, StringType do not have a ScopeIdentifyer/name. This seems problematic,

• PrimitiveTypes do seem to have a name as it is used when defining struct members of that type.
• CollectionTypes do not seem to have a name.

However nothing really says that typenames should be globally unique. They only need to be unique within a compilation unit...

"Member Names" (7.6.7.1) is missing support for Unions. Union members can be accessed by name as long as a reserved name is specified for the discriminator. A valid filter expression needs to check the discriminator before accessing another member name (for example u.disc = 3 AND u.val < 100), however the implementation doesn't need to check for this. If evaluating a filter expression causes access to an inactive element of a union, the result is undefined.