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: 41
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
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-47 Encoding of TypeInformation in SEDP 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-44 Default value and @default annotations DDS-XTypes 1.3 open
DDSXTY13-84 Typo in DataRepresentationMask 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-38 Data Representation for RTPS's Serialized Key DDS-XTypes 1.3 open
DDSXTY14-35 Anonymous Types in Strongly Connected Components DDS-XTypes 1.3 open
DDSXTY14-36 Representing union case labels in TypeObject DDS-XTypes 1.3 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-28 IDL's fixed data type is required in XTypes DDS-XTypes 1.3 open
DDSXTY14-26 XTypes spec is missing topic names for TypeLookupService DDS-XTypes 1.3 open
DDSXTY14-20 Inconsistent Definitions of RTPS Encapsulation DDS-XTypes 1.3b1 open
DDSXTY14-23 Missing alignment for XCDR1 mutable's sentinel DDS-XTypes 1.3b1 open
DDSXTY14-24 TypeFlags usage in normative IDL DDS-XTypes 1.3 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-17 Typo or editing issue 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

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

Encoding of TypeInformation in SEDP

  • Status: open  
  • Source: Kongsberg Defence & Aerospace ( 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: Thu, 17 Jun 2021 20:19 GMT

TypeLookup IDL Inconsistency

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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 ( 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. ( 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

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, 30 Apr 2021 13:35 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, 1 Apr 2021 15:50 GMT

Table 60 - RTPS encapsulation identifier

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: ADLINK Advanced Technology Office ( 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 ( 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: ADLINK Advanced Technology Office ( 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

Data Representation for RTPS's Serialized Key

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( 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, 28 Oct 2020 19:54 GMT

Anonymous Types in Strongly Connected Components

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( 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: Thu, 1 Oct 2020 13:32 GMT

Representing union case labels in TypeObject

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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, 30 Sep 2020 15:29 GMT

Enums with different holder types should not be assignable

  • Status: open   Implementation work Blocked
  • Source: Object Computing, Inc. - OCI ( 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 ( 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 ( 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 ( 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

IDL's fixed data type is required in XTypes

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Tue, 28 Jul 2020 19:40 GMT

XTypes spec is missing topic names for TypeLookupService

  • Status: open  
  • Source: ADLINK Advanced Technology Office ( 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

Inconsistent Definitions of RTPS Encapsulation

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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 byte 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 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: Wed, 8 Jul 2020 04:18 GMT

Missing alignment for XCDR1 mutable's sentinel

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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

TypeFlags usage in normative IDL

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Tue, 30 Jun 2020 19:25 GMT

Can structures contain constant declarations?

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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 ( Gerardo Pardo-Castellote)
  • 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 ( 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 ( 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

Typo or editing issue

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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: Tue, 24 Mar 2020 14:13 GMT

Spec text unclear

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( 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 ( Gerardo Pardo-Castellote)
  • 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 ( 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 ( Gerardo Pardo-Castellote)
  • 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 ( Gerardo Pardo-Castellote)
  • 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 ( Gerardo Pardo-Castellote)
  • 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 ( Gerardo Pardo-Castellote)
  • 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 ( Gerardo Pardo-Castellote)
  • 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 ( Gerardo Pardo-Castellote)
  • 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 ( Gerardo Pardo-Castellote)
  • 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 ( Gerardo Pardo-Castellote)
  • 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 ( 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