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

Issues Descriptions

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