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

Issues Descriptions

Extra fields in IDL of 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 '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 '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 ( 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 ( 'Property: type') which according to 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" ( 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