Extensible and Dynamic Topic Types for DDS Avatar
  1. OMG Specification

Extensible and Dynamic Topic Types for DDS — Open Issues

  • Acronym: DDS-XTypes
  • Issues Count: 34
  • Description: Issues not resolved
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-68 Update IDL definition of union TypeIdentifier in Annex B to account for primitive types DDS-XTypes 1.3b1 open
DDSXTY14-64 Should the TypeObject mark key members as must understand DDS-XTypes 1.3b1 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-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-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-41 Unknown behavior of explicitly negated key in nested struct DDS-XTypes 1.3b1 open
DDSXTY14-37 Ambiguous effect of using annotations on attributes with multiple declarators. DDS-XTypes 1.3b1 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

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

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

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

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

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

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

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

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