${taskforce.name} Avatar
  1. OMG Task Force

DDS Extensible Types (DDS-XTYPES) 1.4 RTF — Open Issues

Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSXTY14-74 Clarify the intended member ID of a union's discriminator DDS-XTypes 1.3b1 open
DDSXTY14-73 Ambiguous definition and/or usage of PUSH(ORIGIN=0) DDS-XTypes 1.3b1 open
DDSXTY14-56 XCDR2 serialization of sequences of non-primitive elements DDS-XTypes 1.3b1 open
DDSXTY14-72 XCDR2 serialization of non-trivial maps DDS-XTypes 1.3b1 open
DDSXTY14-69 Section contains a duplicate sentence from the next section. DDS-XTypes 1.3 open
DDSXTY14-68 Update IDL definition of union TypeIdentifier in Annex B to account for primitive types DDS-XTypes 1.3b1 open
DDSXTY14-59 Clarify accessing discriminator of a DynamicData union DDS-XTypes 1.3 open
DDSXTY14-38 Data Representation for RTPS's Serialized Key DDS-XTypes 1.3 open
DDSXTY14-67 Typos in DynamicData UML Diagrams DDS-XTypes 1.3 open
DDSXTY14-66 Conflicting Order of Minimal Struct and Union Members in TypeObject DDS-XTypes 1.3 open
DDSXTY14-64 Should the TypeObject mark key members as must understand DDS-XTypes 1.3b1 open
DDSXTY14-65 Typo in DataRepresentationMask DDS-XTypes 1.3 open
DDSXTY14-47 Encoding of TypeInformation in SEDP DDS-XTypes 1.3 open
DDSXTY14-53 Description on how to encode Participant GUID in dds::rpc::RequestHeader seems wrong DDS-XTypes 1.3b1 open
DDSXTY14-54 Impossible to handle @must_understand AND @optional fields in an @appendable struct correctly DDS-XTypes 1.3b1 open
DDSXTY14-63 bitset types not defined DDS-XTypes 1.3b1 open
DDSXTY14-61 DynamicTypeSupport IDL defnition is invalid IDL DDS-XTypes 1.3 open
DDSXTY14-60 Table 9 is missing BITMASK_TYPE DDS-XTypes 1.3 open
DDSXTY14-28 IDL's fixed data type is required in XTypes DDS-XTypes 1.3 open
DDSXTY14-36 Representing union case labels in TypeObject DDS-XTypes 1.3 open
DDSXTY14-35 Anonymous Types in Strongly Connected Components DDS-XTypes 1.3 open
DDSXTY14-24 TypeFlags usage in normative IDL DDS-XTypes 1.3 open
DDSXTY14-58 Dynamic Binding: equals() for DynamicType/DynamicTypeMember and related types DDS-XTypes 1.3 open
DDSXTY14-57 Annex C: BoundSeq IDL type not defined DDS-XTypes 1.3 open
DDSXTY14-55 Add support for data-level compression during serialization DDS-XTypes 1.3b1 open
DDSXTY14-17 Typo or editing issue DDS-XTypes 1.3b1 open
DDSXTY14-44 Default value and @default annotations DDS-XTypes 1.3 open
DDSXTY14-52 Missing TK_INT8 and TK_UINT8 in the IDL machine readable file DDS-XTypes 1.3b1 open
DDSXTY14-51 Extensibility of inherited structures DDS-XTypes 1.3b1 open
DDSXTY14-20 Inconsistent Definitions of RTPS Encapsulation DDS-XTypes 1.3b1 open
DDSXTY14-50 Integrate annotations for range/min/max with try_construct DDS-XTypes 1.3b1 open
DDSXTY14-49 Remove all IDL42 specified parts DDS-XTypes 1.3 open
DDSXTY14-48 8 bit types mising in 7.2.1 DDS-XTypes 1.3 open
DDSXTY14-39 TypeLookup IDL Inconsistency DDS-XTypes 1.3 open
DDSXTY14-46 Typo in Member of AnnotationParameterValue DDS-XTypes 1.3 open
DDSXTY14-45 The list of valid KEY types does not include String types DDS-XTypes 1.3 open
DDSXTY14-42 Table 60 - RTPS encapsulation identifier DDS-XTypes 1.3 open
DDSXTY14-41 Unknown behavior of explicitly negated key in nested struct DDS-XTypes 1.3b1 open
DDSXTY14-40 Type Consistency Enforcement QoS Policy ignore_member_names DDS-XTypes 1.3 open
DDSXTY14-37 Ambiguous effect of using annotations on attributes with multiple declarators. DDS-XTypes 1.3b1 open
DDSXTY14-33 Enums with different holder types should not be assignable DDS-XTypes 1.3 open
DDSXTY14-25 7.4.3.5.3 contradictory rules for collections DDS-XTypes 1.3 open
DDSXTY14-27 DataRepresentationQosPolicy default DDS-XTypes 1.3 open
DDSXTY14-29 Specify that TypeLookup Service uses XCDR2 DDS-XTypes 1.3 open
DDSXTY14-26 XTypes spec is missing topic names for TypeLookupService DDS-XTypes 1.3 open
DDSXTY14-23 Missing alignment for XCDR1 mutable's sentinel DDS-XTypes 1.3b1 open
DDSXTY14-21 Can structures contain constant declarations? DDS-XTypes 1.3b1 open
DDSXTY14-19 Confusing description of FINAL on 7.2.3 TypeExtensibilityandMutability DDS-XTypes 1.3b1 open
DDSXTY14-14 Define Implied Keys Behavior DDS-XTypes 1.3b1 open
DDSXTY14-18 7.4.3.5.3 doesn't define OPTIONS DDS-XTypes 1.3b1 open
DDSXTY14-16 Spec text unclear DDS-XTypes 1.3b1 open
DDSXTY14-13 Be more precise on meaning of string lengths and bounds DDS-XTypes 1.3b1 open
DDSXTY14-15 Implementation Defined Default Nested Behavior DDS-XTypes 1.3b1 open
DDSXTY14-12 Need to add an ignore_enum_literal_names in TypeConsistencyEnforcement QosPolicy DDS-XTypes 1.3b1 open
DDSXTY14-11 Clarify whether the algorithm to compute KeyHash is specific to XTYPES DDS-XTypes 1.3b1 open
DDSXTY14-10 Missing parameter in Annex C operation DynamicDataFactory::create_data DDS-XTypes 1.3b1 open
DDSXTY14-8 Extra text left in section 7.2.2.4.4.4.4 Member IDs DDS-XTypes 1.3b1 open
DDSXTY14-6 Extra fields in IDL of 7.8.2.1 create_client DDS-XTypes 1.3b1 open
DDSXTY14-5 Consider referencing DDS-XML for the XML type and data representations DDS-XTypes 1.3b1 open
DDSXTY14-4 Wrong name for DataRepresentationQosPolicy field DDS-XTypes 1.3b1 open
DDSXTY14-2 Specify more clearly which types have a name and how it is constructed DDS-XTypes 1.3b1 open
DDSXTY14-1 Add Unions to types supported in Queries and Filters DDS-XTypes 1.3b1 open

Issues Descriptions

Clarify the intended member ID of a union's discriminator

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

  • Reported: DDS-XTypes 1.3b1 — Thu, 21 Mar 2024 03:51 GMT
  • Updated: Sat, 23 Mar 2024 14:23 GMT

Ambiguous definition and/or usage of PUSH(ORIGIN=0)

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Thu, 21 Mar 2024 03:48 GMT
  • Updated: Thu, 21 Mar 2024 03:49 GMT

XCDR2 serialization of sequences of non-primitive elements

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

  • Reported: DDS-XTypes 1.3b1 — Wed, 4 May 2022 22:43 GMT
  • Updated: Fri, 15 Dec 2023 19:15 GMT

XCDR2 serialization of non-trivial maps

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Tue, 5 Dec 2023 16:36 GMT
  • Updated: Wed, 6 Dec 2023 16:06 GMT

Section contains a duplicate sentence from the next section.

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Fri, 1 Sep 2023 20:42 GMT
  • Updated: Fri, 8 Sep 2023 22:26 GMT

Update IDL definition of union TypeIdentifier in Annex B to account for primitive types

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

  • Reported: DDS-XTypes 1.3b1 — Sat, 12 Aug 2023 02:20 GMT
  • Updated: Wed, 16 Aug 2023 15:56 GMT

Clarify accessing discriminator of a DynamicData union

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Mon, 8 Aug 2022 15:38 GMT
  • Updated: Mon, 14 Aug 2023 15:28 GMT

Data Representation for RTPS's Serialized Key

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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

  • Reported: DDS-XTypes 1.3 — Wed, 28 Oct 2020 19:43 GMT
  • Updated: Wed, 31 May 2023 09:23 GMT

Typos in DynamicData UML Diagrams

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

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

  • Reported: DDS-XTypes 1.3 — Thu, 16 Mar 2023 05:38 GMT
  • Updated: Mon, 24 Apr 2023 18:25 GMT

Conflicting Order of Minimal Struct and Union Members in TypeObject

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    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;

  • Reported: DDS-XTypes 1.3 — Wed, 29 Mar 2023 22:13 GMT
  • Updated: Wed, 5 Apr 2023 22:44 GMT

Should the TypeObject mark key members as must understand

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Tue, 21 Mar 2023 15:27 GMT
  • Updated: Thu, 30 Mar 2023 18:23 GMT

Typo in DataRepresentationMask

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Typo, it says

    @posiiton(2) XCDR2

    but should say

    @position(2) XCDR2

  • Reported: DDS-XTypes 1.3 — Thu, 25 Mar 2021 07:54 GMT
  • Updated: Thu, 30 Mar 2023 18:21 GMT

Encoding of TypeInformation in SEDP

  • Status: open  
  • Source: Kongsberg Defence & Aerospace ( Dr. Ornulf Staff)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Thu, 17 Jun 2021 13:04 GMT
  • Updated: Tue, 21 Mar 2023 15:39 GMT

Description on how to encode Participant GUID in dds::rpc::RequestHeader seems wrong

  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Mon, 20 Dec 2021 16:09 GMT
  • Updated: Tue, 21 Mar 2023 15:36 GMT

Impossible to handle @must_understand AND @optional fields in an @appendable struct correctly

  • Status: open   Implementation work Blocked
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    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?
  • Reported: DDS-XTypes 1.3b1 — Mon, 10 Jan 2022 15:02 GMT
  • Updated: Tue, 21 Mar 2023 15:22 GMT

bitset types not defined

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Mon, 20 Mar 2023 19:15 GMT
  • Updated: Tue, 21 Mar 2023 14:39 GMT

DynamicTypeSupport IDL defnition is invalid IDL

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Fri, 28 Oct 2022 17:45 GMT
  • Updated: Thu, 8 Dec 2022 16:29 GMT

Table 9 is missing BITMASK_TYPE

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Add BITMASK_TYPE to table 9

  • Reported: DDS-XTypes 1.3 — Tue, 15 Nov 2022 22:08 GMT
  • Updated: Tue, 15 Nov 2022 22:08 GMT

IDL's fixed data type is required in XTypes

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

  • Reported: DDS-XTypes 1.3 — Tue, 28 Jul 2020 19:40 GMT
  • Updated: Wed, 21 Sep 2022 20:22 GMT

Representing union case labels in TypeObject

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Tue, 29 Sep 2020 17:46 GMT
  • Updated: Wed, 21 Sep 2022 19:00 GMT

Anonymous Types in Strongly Connected Components

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Wed, 2 Sep 2020 16:25 GMT
  • Updated: Wed, 21 Sep 2022 18:45 GMT

TypeFlags usage in normative IDL

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Enum and bitmask can have extensibility

        typedef TypeFlag   EnumTypeFlag;        // Unused. No flags apply
        typedef TypeFlag   BitmaskTypeFlag;     // Unused. No flags apply
    
  • Reported: DDS-XTypes 1.3 — Tue, 30 Jun 2020 19:25 GMT
  • Updated: Wed, 10 Aug 2022 22:24 GMT

Dynamic Binding: equals() for DynamicType/DynamicTypeMember and related types

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Mon, 8 Aug 2022 14:26 GMT
  • Updated: Mon, 8 Aug 2022 14:26 GMT

Annex C: BoundSeq IDL type not defined

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

  • Reported: DDS-XTypes 1.3 — Tue, 26 Jul 2022 18:01 GMT
  • Updated: Thu, 28 Jul 2022 14:27 GMT

Add support for data-level compression during serialization

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Tue, 1 Feb 2022 19:08 GMT
  • Updated: Tue, 1 Feb 2022 19:08 GMT

Typo or editing issue

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 14:13 GMT
  • Updated: Fri, 21 Jan 2022 06:58 GMT

Default value and @default annotations

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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?

  • Reported: DDS-XTypes 1.3 — Wed, 21 Apr 2021 10:28 GMT
  • Updated: Fri, 21 Jan 2022 02:59 GMT

Missing TK_INT8 and TK_UINT8 in the IDL machine readable file

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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
    
  • Reported: DDS-XTypes 1.3b1 — Tue, 12 Oct 2021 00:51 GMT
  • Updated: Tue, 12 Oct 2021 15:09 GMT

Extensibility of inherited structures

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Thu, 30 Sep 2021 15:28 GMT
  • Updated: Tue, 5 Oct 2021 14:05 GMT

Inconsistent Definitions of RTPS Encapsulation

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    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:

    Type 7.4.3.4 7.6.3.1.2
    Plain XCDR2 0x00, 0x10 0x00, 0x06
    Parameter List XCDR2 0x00, 0x12 0x00, 0x0a
    Delimited XCDR2 0x00, 0x14 0x00, 0x08
    XML 0x01, 0x00 0x00, 0x04

    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.

  • Reported: DDS-XTypes 1.3b1 — Thu, 4 Jun 2020 17:51 GMT
  • Updated: Sat, 2 Oct 2021 00:10 GMT

Integrate annotations for range/min/max with try_construct

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Thu, 30 Sep 2021 14:45 GMT
  • Updated: Thu, 30 Sep 2021 14:45 GMT

Remove all IDL42 specified parts

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Thu, 19 Aug 2021 09:38 GMT
  • Updated: Fri, 20 Aug 2021 06:52 GMT

8 bit types mising in 7.2.1

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: DDS-XTypes 1.3 — Tue, 17 Aug 2021 11:22 GMT
  • Updated: Tue, 17 Aug 2021 22:16 GMT

TypeLookup IDL Inconsistency

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    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
  • Reported: DDS-XTypes 1.3 — Tue, 10 Nov 2020 02:10 GMT
  • Updated: Wed, 16 Jun 2021 22:03 GMT

Typo in Member of AnnotationParameterValue

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Frederick Hornsey)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Mon, 14 Jun 2021 22:07 GMT
  • Updated: Mon, 14 Jun 2021 23:04 GMT

The list of valid KEY types does not include String types

  • Status: open  
  • Source: Twin Oaks Computing, Inc. ( Mr. Clark Tucker)
  • Summary:

    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'.

  • Reported: DDS-XTypes 1.3 — Thu, 6 May 2021 15:53 GMT
  • Updated: Tue, 11 May 2021 13:56 GMT

Table 60 - RTPS encapsulation identifier

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

  • Reported: DDS-XTypes 1.3 — Thu, 11 Mar 2021 15:44 GMT
  • Updated: Thu, 11 Mar 2021 15:44 GMT

Unknown behavior of explicitly negated key in nested struct

  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    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?

  • Reported: DDS-XTypes 1.3b1 — Wed, 27 Jan 2021 15:03 GMT
  • Updated: Fri, 5 Feb 2021 16:25 GMT

Type Consistency Enforcement QoS Policy ignore_member_names

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Mon, 25 Jan 2021 21:40 GMT
  • Updated: Mon, 25 Jan 2021 21:40 GMT

Ambiguous effect of using annotations on attributes with multiple declarators.

  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    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;
    };
    
  • Reported: DDS-XTypes 1.3b1 — Wed, 30 Sep 2020 14:49 GMT
  • Updated: Tue, 8 Dec 2020 15:59 GMT

Enums with different holder types should not be assignable

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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"

  • Reported: DDS-XTypes 1.3 — Wed, 26 Aug 2020 18:09 GMT
  • Updated: Wed, 26 Aug 2020 22:09 GMT

7.4.3.5.3 contradictory rules for collections

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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
    
  • Reported: DDS-XTypes 1.3 — Tue, 30 Jun 2020 20:01 GMT
  • Updated: Tue, 25 Aug 2020 17:40 GMT

DataRepresentationQosPolicy default

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Tue, 28 Jul 2020 19:37 GMT
  • Updated: Tue, 25 Aug 2020 16:15 GMT

Specify that TypeLookup Service uses XCDR2

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Tue, 28 Jul 2020 19:45 GMT
  • Updated: Mon, 24 Aug 2020 19:22 GMT

XTypes spec is missing topic names for TypeLookupService

  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3 — Thu, 4 Jun 2020 20:51 GMT
  • Updated: Tue, 28 Jul 2020 19:28 GMT

Missing alignment for XCDR1 mutable's sentinel

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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 }
    
  • Reported: DDS-XTypes 1.3b1 — Mon, 29 Jun 2020 23:27 GMT
  • Updated: Wed, 8 Jul 2020 04:16 GMT

Can structures contain constant declarations?

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Wed, 10 Jun 2020 23:26 GMT
  • Updated: Wed, 10 Jun 2020 23:26 GMT

Confusing description of FINAL on 7.2.3 TypeExtensibilityandMutability

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Sat, 4 Apr 2020 00:03 GMT
  • Updated: Sat, 4 Apr 2020 00:03 GMT

Define Implied Keys Behavior

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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

    { @key(FALSE) long a1; long a2; }

    ;

    @nested(FALSE)
    struct B

    { @key A b1; }

    ;

    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 KeyedTestUnion switch (@key long) { // ... }

    ;

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

    { // ... }

    ;

    @nested(TRUE)
    struct A

    { TestUnion a1; // discriminator is implied to be part of the key of B KeyedTestUnion a2; // discriminator is explicitly part of the key of B KeyedFalseTestUnion a3; // Not part of the key of B }

    ;

    @nested(FALSE)
    struct B

    { @key TestUnion b1; // discriminator is implied to be part of the key @key KeyedTestUnion b2; // discriminator is explicitly part of the key @key KeyedFalseTestUnion b3; // Not part of the key, maybe an implementation could give a warning? @key A b4; }

    ;

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 13:53 GMT
  • Updated: Tue, 24 Mar 2020 14:29 GMT

7.4.3.5.3 doesn't define OPTIONS

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

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

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 14:26 GMT
  • Updated: Tue, 24 Mar 2020 14:29 GMT

Spec text unclear

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 14:03 GMT
  • Updated: Tue, 24 Mar 2020 14:03 GMT

Be more precise on meaning of string lengths and bounds

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Thu, 19 Mar 2020 20:23 GMT
  • Updated: Tue, 24 Mar 2020 14:01 GMT

Implementation Defined Default Nested Behavior

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Tue, 24 Mar 2020 13:55 GMT
  • Updated: Tue, 24 Mar 2020 13:55 GMT

Need to add an ignore_enum_literal_names in TypeConsistencyEnforcement QosPolicy

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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

  • Reported: DDS-XTypes 1.3b1 — Sat, 2 Mar 2019 00:27 GMT
  • Updated: Fri, 21 Feb 2020 16:27 GMT

Clarify whether the algorithm to compute KeyHash is specific to XTYPES

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

  • Reported: DDS-XTypes 1.3b1 — Fri, 8 Mar 2019 04:13 GMT
  • Updated: Fri, 21 Feb 2020 16:27 GMT

Missing parameter in Annex C operation DynamicDataFactory::create_data

  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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);
    
  • Reported: DDS-XTypes 1.3b1 — Thu, 14 Mar 2019 04:11 GMT
  • Updated: Fri, 21 Feb 2020 16:26 GMT

Extra text left in section 7.2.2.4.4.4.4 Member IDs

  • Key: DDSXTY14-8
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Fri, 21 Feb 2020 00:40 GMT
  • Updated: Fri, 21 Feb 2020 00:40 GMT

Extra fields in IDL of 7.8.2.1 create_client

  • Key: DDSXTY14-6
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.3b1 — Tue, 29 Oct 2019 01:04 GMT
  • Updated: Tue, 29 Oct 2019 01:04 GMT

Consider referencing DDS-XML for the XML type and data representations

  • Key: DDSXTY14-5
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

  • Reported: DDS-XTypes 1.3b1 — Wed, 25 Sep 2019 22:14 GMT
  • Updated: Thu, 26 Sep 2019 08:44 GMT

Wrong name for DataRepresentationQosPolicy field

  • Key: DDSXTY14-4
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    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;
    
  • Reported: DDS-XTypes 1.3b1 — Thu, 15 Aug 2019 00:46 GMT
  • Updated: Thu, 15 Aug 2019 00:46 GMT

Specify more clearly which types have a name and how it is constructed

  • Key: DDSXTY14-2
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

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

  • Reported: DDS-XTypes 1.3b1 — Sun, 4 Aug 2019 20:29 GMT
  • Updated: Mon, 5 Aug 2019 10:06 GMT

Add Unions to types supported in Queries and Filters

  • Key: DDSXTY14-1
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    "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.

  • Reported: DDS-XTypes 1.3b1 — Mon, 22 Jul 2019 15:36 GMT
  • Updated: Mon, 22 Jul 2019 15:36 GMT