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

Issues Descriptions

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.2 — Thu, 14 Mar 2019 04:11 GMT
  • Updated: Thu, 14 Mar 2019 04:13 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.2 — Fri, 8 Mar 2019 04:13 GMT
  • Updated: Fri, 8 Mar 2019 04:13 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.2 — Sat, 2 Mar 2019 00:27 GMT
  • Updated: Sat, 2 Mar 2019 00:27 GMT