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

Extensible and Dynamic Topic Types for DDS — Closed Issues

  • Acronym: DDS-XTypes
  • Issues Count: 156
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSXTY13-22 Description of KeyHash computation needs update to CDR version 2 DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-21 Type compatibility when members types define keys DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-19 Representation of Built-in Annotations in Dynamic Types DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-15 Be explicit about which Types can be used for DDS Topics DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-73 Correct listed inconsistencies & missing items DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-81 Correct XSD issues identified during AB review DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-52 Duplication of sections 7.3.1.2.3 and 7.3.1.2.6 DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-49 Add a Need @data_representation annotation DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-46 Need @data_representation annotation and clean terminology in 7.4.x DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-60 Update Normative references to latest versions of IDL and DDS DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-64 Type compatibility rules for structs with keys DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-40 Restructure Section 7.2 "Type System" to include the annotation semantics & align with IDL 4.2 DDS-XTypes 1.2 DDS-XTypes 1.3 Deferred closed
DDSXTY13-41 Rules for type compatibility are incomplete DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-24 Incomplete application of issue DDSXTY12-18 resolution DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-12 Further corrections DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-11 DynamicType / DynamicTypeBuilder multiplicity of members DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-7 Add support for signed and unsigned 8-bit integers DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-4 XSD for XML type representation should not specify default values for attributes representing annotations DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-2 Algorithm to compute autoid is missing from the specification DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-1 Inconsistencies and missing items DDS-XTypes 1.1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-18 Clarify which of the options bits are set to indicate padding bytes DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-29 Endianess bit in DHEADER causes innefficiencies DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-17 Annotation for denoting topic types DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-5 Typographical corrections and minor rewordings DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-27 Clarify valid ranges of memberIDs DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-26 Setting of @default with @optional members DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-20 Reseting the alignment after Encapsulation Header DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-23 Inheritance rules not sufficient regarding keys and memberID assignment DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-43 Organization of section 7.2.2.4.4 is confusing DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-36 Remove Endianness bit from DHEADER DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-32 Ambiguity in Table 9 and Obsolete language in section 7.3.1.2.1.10 DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-42 Compatibility of Enum should be allowed even if there is just one common literal DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-10 Union discriminator value without associated member DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-16 Provide a more efficient serialization for short strings and sequences DDS-XTypes 1.2 DDS-XTypes 1.3 Deferred closed
DDSXTY13-6 Restrictions on MAP key element type should include ENUM DDS-XTypes 1.2b1 DDS-XTypes 1.3 Closed; No Change closed
DDSXTY13-31 Redefinition of the LC=6 and LC=7 DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY13-28 Computation of KeyHash (7.6.7 Interoperability of Keyed Topics) needs additional detail DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-8 The definition of ReliabilityQosPolicyKind in Annex D is inconsistent with RTPS DDS-XTypes 1.2 DDS-XTypes 1.3 Duplicate or Merged closed
DDSXTY13-13 Union default values (Table 9) DDS-XTypes 1.2b1 DDS-XTypes 1.3 Resolved closed
DDSXTY13-9 Explicitly define the values for ReliabilityQosPolicyKind DDS-XTypes 1.2 DDS-XTypes 1.3 Resolved closed
DDSXTY12-145 Users should have more control over when and how types match DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-147 Computing the TypeObject and TypeId for recursive types DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-149 UML Model is not consistent with document and missing types DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-148 Fix a Number of Issues in Final Document DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-142 XTypes impacts on IDL and language mappings; optional conformance DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-18 Improving Extensible Types DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-15 Type Consistency Enforcement Policy does not allow to properly control type projection/widening DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-143 Enumerations should be represented as a Byte if the bit bound is small enough DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-131 Add a @non-serialized annotation DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-100 TypeObject IDL and its propagation suffers from significant problems DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-127 Consider expanding TypeId 16 octets rather than 8 DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-119 The current assignability rules are complex and too restrictive DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-41 Reserved parameter IDs in 7.4.1.2.1 are wrong DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-45 Extended PID is not clear enough what the 2 value lengths mean DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-19 Proposed type-naming scheme is far from Robust DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-122 Align with IDL4 DDS-XTypes 1.2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-113 The encoding of strings and wide strings should be standardized DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-118 Misleading formulation DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-40 Section 7.4.1.2.2 "Member ID-to-Parameter ID Mapping" is underspecified DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-38 ths XSD has many errors DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-28 Mapping of Map type underspecified for C DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-27 C++ shared member representation breaks safety mechanisms of the struct containing it DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-9 Contradictions in the assignability for collection types DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-12 Mapping of optional arrays in C/C++ DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-112 Unify name used for Aggregate and Enumerated types DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-42 Built-in annotations should be in DDS namespace DDS-XTypes 1.0b2 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-44 Rendering of UML diagrams in each of the figures is of poor graphical quality DDS-XTypes 1.0b2 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-43 All IDL should use local interfaces DDS-XTypes 1.0b2 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-39 Extended parameters should be aligned the same as non-extended ones DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-36 IDL annotation syntax fails to specify scoping rules for annotation type names DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-10 Deserialization issues with Extensible types DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-5 Issues with UNIONS assignability rules DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-20 Applicable key types not clearly specified DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-29 DataRepresentationQosPolicy is making the application responsible for transport DDS-XTypes 1.1 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-17 A @Version annotation shall be added DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-16 Key order should be defined using the @Key annotation DDS-XTypes 1.1 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-14 Allow empty structures DDS-XTypes 1.1 DDS-XTypes 1.2 Closed; Out Of Scope closed
DDSXTY12-23 member ID algorithm flawed DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-35 IDL annotation syntax does specify how to use Any member type DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-34 Annotation member default declaration not compatible with Legacy IDL DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-33 Builtin topics not backward compatible DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-48 Expose assignability options for ignoring member names and sequence lengths DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-47 Keyhash computation not well-defined for mutable types DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-46 specify language-specific bindings may exist DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-37 One sentence split in two bullets DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-6 Spec should allow any value for the Optional flag in TypeObject union members DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-13 Optional flag in TypeObject union members DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-11 Optional flag in TypeObject union members DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-4 The description for union types are not complete DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-32 lookup_topicdescription semantics make it unusable DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-30 Multiplicity mismatch between TypeName and TypeObject DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-21 Shareable members underspecified DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-8 Circular dependencies across types should be allowed DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-7 TypeId calculation errors/corrections DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-26 XML type description not orthogonal and not consistent DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-25 Type system severely underspecified DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-24 TypeObject semantics underspecified and inconsistent DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-22 Definition of "strongly assignable" seems to be used inconsitently DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-3 TypeId union is missing NO_TYPE from the possible values of the discriminator DDS-XTypes 1.1 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-2 Send TypeId independently of the TypeObject DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-31 Topic incosisstency only considered for incompatible types, not for incompatible qos DDS-XTypes 1.1 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-1 Specification document cleanup DDS-XTypes 1.1 DDS-XTypes 1.2 Resolved closed
DDSXTY12-158 Inconsistencies and missing items DDS-XTypes 1.1 DDS-XTypes 1.2 Deferred closed
DDSXTY11-12 Not every application limits itself to only 1 representation of a topic DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-11 Semantics of overriding an attribute not clearly specified DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-10 Typo DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-9 Typo in opening sentence of section: Missing noun and verb DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-8 Inconsistent extensibility kind for enumerations DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY_-26 DynamicData interface of the Language Binding section DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-25 Inconsistent generated code for DynamicType::descriptor DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-24 Circular reference in definition of specialized Primitive Types DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-19 Introduce the notional value "null" that may be used in a content-filter expression DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-23 Invalid data types applied to AnnotationDescriptor::value, DynamicData::descriptor, DynamicData::value DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-22 Conflicting data types applied to several Attributes, Operations and Parameters in UML notation DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-21 Non-standard UML notation on figures DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-20 Truncation of text in Figure 3 DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-18 New DDS-XTypes issue: inability to consume data using new base class DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-17 Object assignability rules should be more resilient DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-16 Definition of “strongly assignable” is incomplete DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-12 Incorrect default extensibility kind value in XSD file DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-15 Incorrect union assignability rules DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-14 Inconsistent bit set/integer equivalency DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-13 Ambiguous description of serializing discovery types DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-9 Difficult to apply automation to statically defined types DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-8 Changing a DynamicType object is ambiguous DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-11 Optional, must_understand members of non-mutable aggregation types cannot be accurately represented in CDR DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-10 New QoS policies don’t indicate whether they can be changed DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-7 Typographical errors DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-6 Type signature fields in built-in topic data shouldn't use unbounded strings DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-5 No way to get or set length of collection-typed DynamicData objects DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-4 Annex D (“DDS Built-in Topic Data Types”) is out of sync with IDL file DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-3 C++ mapping MAP type needs member access semantics specification DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-2 Restrictions on MAP key element type not (clearly) documented/specified DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-1 Anonymous types should not be used in IDL examples and the TypeObject representation IDL DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY-29 Different applications in the same domain may associate the same Topic with different types DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-28 DDS-XTypes @Key annotation Issue DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-8 Can’t initialize TypeId from TypeKind DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-9 Identifiers TypeId and Module collide with IDL keywords DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-23 Don’t require CORBA namespace for primitive types in Plain Language Binding DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-22 Allow more flexible type consistency enforcement DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-21 Typographical errors DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-20 Mutable structures with an empty intersection should not be considered assignable DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-19 XML representations should define namespaces DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-25 Provide minimal backwards-compatible conformance point DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-24 Provide formal grammar for new IDL Type Representation constructs DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-27 Improve support for shared data DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-26 Reduce size of DynamicData API DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-16 Incorrect FooDataWriter overloads for built-in types DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-15 Missing definitions of TypeSupport specializations for built-in types DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-18 Allow IDL compatibility pragma declarations to nest DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-17 Consolidate IDL built-in annotations in machine-readable file DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-14 Updated QoS definitions should be provided DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-13 Extensibility kinds of new QoS policies are not specified in a consistent way DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-11 Unclear member names when programming language doesn’t support typedef DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-10 Definition of built-in IDL annotation @Shared is missing DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-12 Definition of type “Parameters” inadvertently missing DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed

Issues Descriptions

Description of KeyHash computation needs update to CDR version 2

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The [RTPS] version referenced in section 3 is version 2.2. It should be updated to version 2.3.
    The reference to [RTPS] in [RTPS] Clause 9.6.3.3, “KeyHash (PID_KEY_HASH)”, should change to [RTPS] Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)”. This is because the section number changed in RTPS 2.3.

    Section 7.6.7 was not fully updated to account for CDR version 2. For example it does not clearly state whether DHEADER is serialized for the purposes of computing the KeyHash.

    Also the sentence about backwards compatibility is no longer relevant.

    The decision of whether to serialize DHEADER or not should be taken as soon as possible as it would affect interoperability.

  • Reported: DDS-XTypes 1.2 — Fri, 20 Apr 2018 12:56 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Update 7.6.7 with more complete description of KeyHash computation

    Update section 3 [RTPS] to reference version 2.3.

    Define the KeyHash computation in a more unambiguous as described below.

    Take the AggregatedType "Foo" that is the container of the key members for which we want to compute the key hash.
    For the purposes of computing the key hash, define a key holder type FooKeyHolder as follows.

    • Start with the original Foo type
    • Remove any no-key members
    • Reorder the key members in the order of memberId (this handles the cases where the AggregateType is Final/Appendable/Mutable).
    • Apply this recursively to the types of the key members if they are of an AggregatedType.

    Consider FooKeyHolder (and any KeyHolder types resulting from key members that were of an AggregatedType) as having @extensibility(FINAL).

    After FooKeyHolder has been constructed. We have two cases:

    (a) If the maximum Serialized Size of FooKeyHolder <= 16 then KeyHash = CDR_BigEndian(FooKeyHolder)
    (b) If the maximum Serialized Size of FooKeyHolder > 16, then KeyHash = MD5(CDR_BigEndian(FooKeyHolder))

    CDR_BigEndian uses XCDR version 2 encoding rules and assume serialization on a 4-byte aligned buffer.

    Therefore the resulting serialized type does not have any encapsulation header, not any DHEADER (from Appendable/Mutable types) nor any MemberHeader (from Mutable types), and uses a maximum alignment of 4-bytes.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Type compatibility when members types define keys

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Assume the following:

    @appendable
    struct T1 {
       @key long m1; 
    }
    
    @appendable
    struct T2 {
      @key long m2;
      @key long m3;
    }
    
    struct MyType1  {
      T1 t1; 
      long ll1;
    } 
    
    struct MyType2  {
      T2 t1;
      long ll1;
    }
    

    According to the type-compatibility rules MyType1 and MyType2 are not compatible because T1 is not compatible with T2.

    The reason T1 is not compatible with T2 is due to having different keys. But the keys of T1 and T2 do not play any role in MyType1 and MyType2 because these types did not declare those respective member as key.

    So the current compatibility rules are too restrictive. They should be amended to allow MyType1 and MyType2 to be compatible.

  • Reported: DDS-XTypes 1.2 — Fri, 20 Apr 2018 12:40 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Modify type compatibility rules for Aggregated Types

    Modify the type assignability rules to differentiate the requirements form members that are part of the key of the aggregated type from those that are not part of the key.

    The assignability of members that are not part of the key of the enclosing type should not take into consideration the key members of the nested type.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Representation of Built-in Annotations in Dynamic Types

  • Status: closed  
  • Source: MilSOFT ( Mr. Serdar Baklan)
  • Summary:

    A dynamic type cannot be marked as final, mutable or nested and a dynamic type member cannot be marked as key, optional, shared or must_understand easily with the current specification. Only MemberDescriptor has a boolean field "union_default" to represent whether the union member is the default one. Annotations can be used of in the dynamic API but the usage is a bit cumbersome. Is it considerable to append TypeFlag and MemberFlag fields to TypeDescriptor and MemberDescriptor in order to represent built-in annotations in dynamic types as in TypeObject?

  • Reported: DDS-XTypes 1.2 — Wed, 11 Apr 2018 14:18 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    TypeDescriptor and MemberDescriptor with information about the built-in annotations.

    As indicated in the issue description, the MemberDescriptor and TypeDescriptor types need additional members that provide the value of the builtin annotations.

    Define an enum for TypeKind. This was referenced in TypeDescriptor and MemberDescriptor but never defined.
    Define an enum for ExtensibilityKind
    Define an enum for TryConstructKind
    Define VerbatimTextDecriptor

    Add the following fields to MemberDescriptor: is_key, is_optional, is_must_understand, is_shared, try_construct_kind

    Add the following fields to TypeDescriptor: is_nested, extensibility_kind

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Be explicit about which Types can be used for DDS Topics

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification is not explicit about which Types may be used for a DDS Topic.

    By convention most DDS implementations have supported structures. However it is not clear if unions are allowed. And even less so if collections, strings, or primitives can be used.

    Annex E: Built-in Types defines as builtin the types: String, KeyedString, Bytes, and KeyedBytes.

    The DDS specification also does not say anything explicitly. However the fact that it talks about the type-specific code for a type "Foo" namely "FooSupport" "FooDatWriter", etc. may be taken to imply that this must be constructed types that are given a name. e.g. "Foo" by the user. And not primitive types.

    It would be better if the XTYPES spec was explicit about this.

  • Reported: DDS-XTypes 1.2 — Tue, 9 Jan 2018 12:58 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Specify that only Aggregated Types (structure and union types) may be used as a DDS Topic Type

    Aggregated Types are the only ones that have members and allow the possibility of specifying a Key. For this reason the are the only ones suitable for being Topic-Types.

    Specify this restriction following section 7.6.1 'Topic Model'.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Correct listed inconsistencies & missing items


Correct XSD issues identified during AB review

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The AB review identified two critical issues with the XSD changes made by various issue resolutions that need to be fixed:

    • The resolution of DDSXTY13-1 modified the definition of xs:group moduleElements and changed the name of the first element from "include2" to "include" this causes the XSD to be invalid because it conflicts with the name of another element in the definition of xs:complexType moduleDecl
      . This change should be reverted.
    • The resolution of DDSXTY13-4 updated the file "DDS XTypes 1.3 XML Type Representation, No Namespace, Schema file" removing default values for attributes. However it failed to update the contents of Annex A with contain the same XSD definitions.
    • The attribute value minOccurs="1" is unnecessary for element declarations because it matches the default value when the attribute is not specified. It should be removed from Annex A and the file "DDS XTypes 1.3 XML Type Representation, No Namespace, Schema file"
  • Reported: DDS-XTypes 1.2 — Fri, 8 Mar 2019 07:26 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Update Annex A and the "XML Type Representation, No Namespace, Schema file"

    Apply the corrections indicated in the issue description.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Duplication of sections 7.3.1.2.3 and 7.3.1.2.6

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Sections 7.3.1.2.3 'Alternative Annotation Syntax' and 7.3.1.2.6 'Alternative Syntax' contain identical contents. It seems like the section was moved and one was not properly removed.

    One of this two sections should be deleted.

  • Reported: DDS-XTypes 1.2 — Wed, 28 Nov 2018 07:37 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Remove 7.3.1.2.6 'Alternative Syntax'

    It is better to keep 7.3.1.2.3 'Alternative Annotation Syntax' and remove 7.3.1.2.6 'Alternative Syntax' because section 7.3.1.2.3 references the alternative annotation syntax.

    Therefore the resolution of this issue should just remove section 7.3.1.2.6 'Alternative Syntax'

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Add a Need @data_representation annotation

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Add the @data_representation annotation as proposed in the issue description. Also clean up the terminology when talking about PLAIN_CDR, PL_CDR, etc. refer to those as "encodings" rather than "representations"

  • Reported: DDS-XTypes 1.2 — Wed, 28 Nov 2018 04:01 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.3
  • Disposition Summary:

    Duplicates DDSXTY13-46

    Close as duplicate

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Need @data_representation annotation and clean terminology in 7.4.x

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently the DataRepresentation (XCDR1, XCDR2, XML) is controlled by a Qos Policy on the DataWriter. This is good to allow run-time configurability and enable systems to evolve.

    However when defining data models for systems that will be deployed it may be important to allow that representation to be declared and restricted in the data-model. This may be needed such that the users of that data model can be sure to interoperate with the deployed system. This also supports the use-case where systems are deployed with code that support only one representation as may be the case in some resoure-constained systems.

    A proposed solution is to add an annotation:

    enum DataRepresentationKind {
        XCDR_AND_XCDR2,
        XCDR,
        XCDR2,
        XML
    };
    
    @annotation data_representation {
        DataRepresentationKind value default XCDR1_AND_XCDR2;
    };
    

    If @data_representation is not specified then the default is XCDR_AND_XCDR2. This allows the representation to be configured on the DataWriter and DataReader DataRepresentationQos policy.

    If a value other than XCDR_AND_XCDR2 is specified, then that setting overrides the DataRepresentationQos that may have been set on the DataWriter or DaraReader.

    In addition the terminology for 7.4.x could be cleaned up a bit. Fist it cases about XCDR and XML as being "Data Representations" however later on it talks about PLAIN_CDR and DELIMITED_CDR, PL_CDR2 also as "representations". It may be better to use a different word for this to avoid confusion.

    Keep "Representation" for XCDR, XCDR2, XML, etc. This is consistent with the Qos policy and the main definitions. Use another word. For example "encoding" to talk about PLAIN_CDR, PL_CDR, etc.

  • Reported: DDS-XTypes 1.2 — Tue, 27 Nov 2018 02:31 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Define a @allowed_data_representation annotation

    Add an annotation that can be applied to types and modules that restricts the data representations that a type may use.

    The definition should be as proposed in the issue description.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Update Normative references to latest versions of IDL and DDS


Type compatibility rules for structs with keys

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The compatibility for structure in section 7.2.4.4.8 'Aggregated Types' would make two structures that have a key member of type string compatible even if the keys had different maximum lengths.

    This is problematic. It would result in potentially aliasing different objects and also in different decisions on how the KeyHash is computed.

  • Reported: DDS-XTypes 1.2 — Thu, 6 Dec 2018 16:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.3
  • Disposition Summary:

    Duplicates DDSXTY13-21

    Duplicates DDSXTY13-21

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Restructure Section 7.2 "Type System" to include the annotation semantics & align with IDL 4.2

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.2.2 should include all the Type-System concepts that are related to all the "relevant" annotations in IDL 4.2 (likely groups for "General Purpose", "Data Modeling", "Units and Ranges", "Data Implementation", and "Code Generation") in addition to extra concepts in XTYPES that are not part of IDL4 like Try Construct Behavior, Non-Serialized.

    After 7.2.2.6 Annotations there should be a section on the "Builtin Annotations" these should references the ones IDL 4.2 as well as the extra ones in XTYPES.

    Much of the text in existing section 7.3.1.2.1 should me moved to 7.2.x. These are general concepts independent of the use of IDL.

    Table 7.3.1.2.2 Using Built-in Annotations should be also moved to 7.2.2.x.

    In place of 7.3.1.2.1 there should be a table that maps the "builtin" annotations in the XTYPES type system to their IDL4 syntax. For the most part this references the corresponding annotation in IDL 4.2 except for the new ones introduced by XTYPES.

    7.3.2.x and Annex A should define how the builtin annotations are represented in XML.

    Annex B should be augmented with any missing annotations. It appears @default is missing from the COMPLETE TypeObject.

  • Reported: DDS-XTypes 1.2 — Tue, 25 Sep 2018 21:34 GMT
  • Disposition: Deferred — DDS-XTypes 1.3
  • Disposition Summary:

    Defer to the next RTF

    This reorganization is worthwhile but it would introduce a lot of changes that overlap with those of other issue resolutions. Therefore it is best deferred to the next RTF.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Rules for type compatibility are incomplete

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Table 19, on the compatibility of STRUCTURE_TYPE it says:

    AND if T1 is appendable, then any members whose member ID appears both in T1 and T2 have the same setting for the ‘optional’ attribute and the T1 member type is strongly assignable from the T2 member type.

    This is missing the rule about members having that have the same ID must also have the same index. This rule was present in version rsion xtypes v 1.1 and somehow was lost in version 1.2.

  • Reported: DDS-XTypes 1.2 — Wed, 26 Sep 2018 03:22 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    *Edit Table 19, rule for STRUCTURE_TYPE *

    Edit Table 19, rule for STRUCTURE_TYPE adding that for APPENDABLE and FINAL the member indices must match.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Incomplete application of issue DDSXTY12-18 resolution

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The resolution of DDSXTY12-18 was not applied correctly to section In Section 7.6.2.1.1 (DataRepresentationQosPolicy: Conceptual Model).

    According to that resolution the bullet below:

    • Readers belonging to implementations of XTYPES version 1.2 and later:

    Should appear directly above the 3 sub-bullets that start with:

      • Shall generate or include run-time code that can deserialize version 2 encodings.

    However in the final document that bullet is missing.

  • Reported: DDS-XTypes 1.2 — Tue, 15 May 2018 00:16 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Add the missing bullet to Section 7.6.2.1.1

    Add the missing bullet per issue description.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Further corrections

  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    7.2.1.1 (Type Evolution Example) pg 13 first para

    > [ ...] However, not all components that publish or subscribe data of this
    > type will be upgraded to this new definition of VehicleLocationType
    > (or if they will not be upgraded, they will not be upgraded at the same
    > time)

    • (or if they will be upgraded, they will not be upgraded at the same time)

    7.2.1.3 (Sparse Types Example) pg 14 first para

    > [...] In its local programming language (say, C++ or Java), the
    > application can assign a pointer to null to omit a value for these fields.

    • the application can assign null to a pointer to omit [...]

    7.2.2.2 (Primitive Types) pg 18 Table 3 description for INT_16_TYPE

    > Signed integer minimally capable of representing values in the range
    > -32738 to +32737.

    • -32768 to 32767.

    7.2.2.2.1.2.1 (Use of Unicode) pg 20 fourth para

    > [...] The UTF-8 representation ISO-8859-1 characters that are not in the
    > ASCII subset uses two 8-bit code units.

    • The UTF-8 representation of ISO-8859-1 characters [...]

    7.2.2.2.1.2.5 (CHAR_16_TYPE) pg 21 Rationale second para

    > [...] Restricting to the BMP ensures that each coodepoint is [...]

    • codepoint

    7.2.2.7 (Try Construct behavior) pg 42 first para

    > [...] Similar to the structure examples there exist be objects of type
    > SEQ1024 [...]

    • [...] there may exist objects of type SEQ1024 [...]

    7.2.4.1 (Constructing objects of one type from objects of another type)
    pg 46 Table 13 column "Type compatibility" bottom

    > All objects of type T1 can either be used to
    > construct an object of type T1 or reliably de-
    > tected that that cannot initialize T1. .

    Please check - my guess is:

    • [...] construct an object of type T2 or it can be
      reliably detected which objects of type T1 cannot initialize T2.

    7.2.4.4.5.1 (Example: Strings) pg 49 first para

    > [...] If a
    > consumer of strings of narrow characters were to attempt to consume
    > that string, it might read
    > consider the first byte of the first character [...]

    • Omit the word "read" :
      [...] were to attempt to consume that string, it might consider [...]

    Table 19 (Definition of the is-assignable-from relationship for aggregated types)
    pg 53 second column fourth (i.e. last) bullet

    > If T1 (and therefore T2)
    > extensibility is final then the set of
    > labels are identical.

    • [...] then the set of labels is identical.

    7.3.1.1.1 (Backward Compatibility with Respect to Type Definitions)
    pg 60 bullet "Group of Annotations" fourth sub-bullet

    > * Code Generation (sub clause 8.3.5 [IDL41]) his specification retains
    > well-
    > established IDL type definition syntax, such as enumeration, structure,
    > union, and
    > sequence definitions.

    Appears to be a formatting problem, I think the last part of that phrase should be outside and after the end of the bullet enumeration:

    • Code Generation (sub clause 8.3.5 [IDL41])

    This specification retains well-established IDL type definition syntax, such as enumeration, [...]

    7.3.1.2.2 (Using Built-in Annotations) pg 70 first sentence

    > The application of the annotations listed above is restricted to the
    > elements of specified in Table 21.

    • [...] is restricted to the elements of IDL specified in Table 21.

    7.3.1.10 (Structure Types) pg 76 first sentence

    > Structures as described in this specification are in this specification are
    > fully compatible with the IDL constructs of the same name.

    • Structures as described in this specification are fully compatible [...]

    7.3.1.11 (Union Types) pg 76 first sentence

    > Unions as described in this specification are in this specification are
    > fully compatible with the IDL constructs of the same name.

    • Unions as described in this specification are fully compatible [...]

    7.3.2.4.3 (Map Types) pg 80 first bullet

    > * The map’s bound, if any, shall be indicated by the mapMaxLength
    > attribute. This attribute is required for all map types.

    For more fluent reading, I suggest:

    • The map's bound shall be indicated by the mapMaxLength attribute.
      This attribute is required for all map types.
      In case of an unbounded map, mapMaxLength shall be set to "-1".

    7.3.2.4.3 (Map Types) pg 81 non-normative example:

    > <struct name="MyStructure">
    > <member name="my_unbounded_maps_of_integers_to_floats"
    > type="int32"
    > mapKeyType="float32"
    > mapMaxLength="-1"/>

    The values for "type" and "mapKeyType" are swapped, they should be:

    • type="float32"
    • mapKeyType="int32"

    7.5 (Language Binding) pg 133 top of page (2nd sentence)

    > The main characteristics and motivation for each of these binding are
    > described in Table 41.

    • [...] for each of these bindings are described in Table 41.
  • Reported: DDS-XTypes 1.2b1 — Sun, 3 Dec 2017 21:11 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Perform the corrections suggested in the issue description

    Perform the corrections indicated in the issue description.
    Note that some of the issues indicated in the description were already resolved as part of the editorial corrections performed by OMG editors. This issue addresses the ones that were not caught in that step.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

DynamicType / DynamicTypeBuilder multiplicity of members

  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    In the DDS-XTypes 1.2beta1 document, the UML class diagram in section 7.5.2.8 Figure 30 on p. 175 does not show the multiplicity relationship between DynamicType and DynamicTypeMember for the case of aggregated types.
    In other words, the fact that a DynamicType struct/union/valuetype may have more than one member is not visible in the diagram.

    The section 7.5.2.9 DynamicTypeBuilder does define an operation add_member which can be used to add members to aggregated types. However, DynamicTypeBuilder also does not provide a method for iterating over the members thus added.

    If it is intended that the management of and iteration over the sequence of DynamicTypeMembers shall lie outside of DynamicType / DynamicTypeBuilder, I suggest adding an explanation to that end.

  • Reported: DDS-XTypes 1.2b1 — Sun, 3 Dec 2017 19:47 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Update Figure 30 'Dynamic Type' and operations of DynamicTypeBuilder and DynamicType

    Update the of multiplicity of DynamicTypeMember in Figure 30 'Dynamic Type' (section 7.5.2.8) from "0..1" to "0..*"

    Add operations to 7.5.2.9 'DynamicTypeBuilder' that allow figuring out the number of members and iterate over them.
    Add operations to 'DynamicType' to find the number of members and iterate over them.

    Order operations alphabetically.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Add support for signed and unsigned 8-bit integers

  • Key: DDSXTY13-7
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS Type System does not provide a way to represent signed and unsigned 8-bit integers. IDL 4.2 has introduced the int8 and uint8 types for this purpose, but DDS-XTYPES is still missing those in the model.

    Support for 8-bit signed and unsigned integers is required by some RFP submissions, such as the OPC UA/DDS Gateway RFP.

  • Reported: DDS-XTypes 1.2 — Thu, 30 Nov 2017 14:42 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Include support for signed and unsigned 8-bit integers

    Add two primitive types: Int8 and UInt8 (INT8_TYPE and UINT8_TYPE) to the type system in section 7.2.x

    Add these two types wherever Integer Types are used.

    Use the IDL int8 and uint8 to represent them in in the IDL Type Representation (section 7.3.1.x).

    In the XML Type Representation (section 7.3.2.x) use "int8" and "uint8" as the XML Type Representation name (Table 26).

    Add support for these two types to the TypeIdentifier and TypeObject (section 7.3.4.x)

    Add the rules to serialize those types to 7.4.x
    Add the language mappings to 7.5.1.1.x

    Add these two types to Annex A, Annex B, Annex C.

    Mention in F.1 that legacy implementations do not support int8 and uint8.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

XSD for XML type representation should not specify default values for attributes representing annotations

  • Key: DDSXTY13-4
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The XML type representation (Section 7.3.3) has an associated XSD that defines the legal XML documents that define DDS Types.

    In the XML type representation builtin annotations on members appear as "attributes" on the element that describes the member. For example see example in section 7.3.2.5.1.2 (Members):

    <struct name="structMemberDecl">
       <member name="my_key_field" type="int32" key="true" optional="false"/>
    </struct>
    

    These builtin annotations (key, optional), have default values when they are not present. This is defined in the IDL4+ specification. For example when the annotation "key" is not present, the (default) value is "false" when annotation "optional" is not present, the (default) value is "false". There is also a "default" value when the annotation is present with no parameters, but this is not allowed in the XSD.

    According to the XSD syntax, e.g. see https://www.w3schools.com/xml/schema_simple_attributes.asp

    The "default" value specified for an attribute is the value interpreted when the attribute is not present. Therefore we have two options:

    • Have the XSD specify default values for these attributes to match the "IDL4+ defaults when the attribute is not present
    • Have the XSD specify no default value.

    Currently this is not done correctly for some annotations. For example the XSD for structure members has wrong defaults for all the attributes:

      <xs:complexType name="structMemberDecl">
        <xs:complexContent>
          <xs:extension base="memberDecl">
           <xs:attribute name="id"
                         type="memberId"
                         use="optional"/>
    
            <xs:attribute name="optional"
                          type="xs:boolean"
                          use="optional"
                          default="true"/>
            <xs:attribute name="mustUnderstand"
                          type="xs:boolean"
                          use="optional"
                          default="true"/>
            <xs:attribute name="nonSerialized"
                          type="xs:boolean"
                          use="optional"
                          default="true"/>
            <xs:attribute name="key"
                          type="xs:boolean"
                          use="optional"
                          default="true"/>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>
    

    However it seems like the best solution is to remove the specification of a default value from the XSD. The problem is that when the default is specified the XSD parsers will fill the default value even if the attribute is not specified and it becomes impossible for the application that uses the parser to know if the attribute was there or not in the first place. This would make it impossible to transform between IDL and XML and back to IDL and get the same result back because all annotations would appear present to the XML parser even if they were not entered buy the user.

    Therefore we recommend removing the specification of 'default" value for all XML attributes that correspond to builtin annotations. This should be done both in Annex A and the machine readable dds-xtypes_type_definition_nonamespace.xsd

  • Reported: DDS-XTypes 1.2 — Mon, 24 Apr 2017 16:16 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    *Remove the 'default" value for all XML attributes that correspond to builtin annotations. *

    For the reasons listen in the issue description the XSD should not specify any default values for XSD attributes that correspond to builtin annotations.

  • Updated: Tue, 8 Oct 2019 17:55 GMT
  • Attachments:

Algorithm to compute autoid is missing from the specification

  • Key: DDSXTY13-2
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not define how memberIDs are computed in the case where the @autoid (or @hashid) annotations are used. This is needed for interoperability.

    Section 7.3.1.2.1.1 (Member IDs) specifies there are thee ways to set them:

    • Automatically following a progression that starts from the most-recently specified member ID.
    • Using the @id annotation
    • As a "hash" on the member name when @autoid(HASH) is specified
    • as a "hash" on a string-parameter when @hashid("string-parameter") is specified

    The use of @autoid refers to sub clause 8.3.1.2 in [IDL41]). But there also there is no specification of how the hash should be computed. Only that a "hashing" algorithm should be used.

    IDL working group discussed this and the preference was to leave it unspecified in IDL4 and instead put it in XTYPES or whichever specification depends on these IDs.

    A proposal would be to use an MD5 (as this is already used for key hashing).
    This needs to be done in a platform-independent manner, for example hashing a serialized representation of the string using a pre-specified endianness. Also per section 7.2.2.4.4.3 (Member IDs) the value/range must be representable in 28 bits.

  • Reported: DDS-XTypes 1.2 — Fri, 7 Apr 2017 00:44 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Use the same hash algorithm specified for the TypeObject (Minimal)

    The (normative) IDL for the TypeObject (Minimal Representation) already requires hashing of member names. This is exercised in the (non-normative) example serializations included as part of XTYPES 1.2.

    The algorithm used for this hashing of member names is described as a comment in the dds-xtypes_typeobject.idl

        // First 4 bytes of MD5 of of a member name converted to bytes
        // using UTF-8 encoding and without a 'nul' terminator.
        // Example: the member name "color" has NameHash {0x70, 0xDD, 0xA5, 0xDF}
        typedef octet NameHash[4];
    

    Although this hash algorithm is only specified for the TypeObject and not the MemberId it would make things simpler to use the same algorithm for the @autoid and @hashid. It is also more efficient that doing a CDR serialization because it saves the length and the trailing NUL.

    We still need to specify how to transform the octet[ 4 ] NameHash into a integer memberId with 28-bits of precision so we can all the 4 bits of flags specified in the MemberId format. This basically requires interpreting the NameHash as having a specific endianness.

    Section 7.6.2.3.3 'TypeLookup Types and Endpoints' provides some examples of NameHash that use Big Endian. For example it says that @hashid("getTypes") is a long with value = 0xd35282d1. Note that the md5("getTypes") is the octet sequence d35282d177f1c8e43144c7e65820d7ae. So value = 0xd35282d1 corresponds to the first 4 bytes interpreted as a BigEndian.

    Therefore an Endianess needs to be specified such that an octet[ 4 ] containing the first 4 bytes of the MD5 can be interpreted as an integer. For example if we had chosen Little Endian the NameHash =

    {0x70, 0xDD, 0xA5, 0xDF}

    would be interpreted as the integer: 0xDFA5DD70.

    We still need to zero 4 bits of this to truncate it to the 28 bits of the memberId and allow the addition of the must-understand flag (M_FLAG) and the length code (LC).

    Table 39 in section 7.4.3.3 specifies that the enhanced mutable header is computed as:

    EMHEADER1 =  (M_FLAG<<31) + (LC<<28) + M.id
    

    This means that we need to clear the 4 most significant bits from the member id (bits 29-32).

    The resolution is to explicitly provide the algorithm used to compute the member ID from a NameHash. This algorithm interprets the NameHash as a Big Endian integer. Using C pseudo code the construction of the member_id from a NameHash would be as follows:

        uint32_t  hash_as_int;
        uint32_t  member_id;
    
    #ifdef (MACHINE_IS_BIG_ENDIAN)
        hash_as_int = *((uint32_t *) NameHash);
    #else
        hash_as_int = *((uint32_t *)EndianessSwap4Bytes(NameHash));
    #endif
    
    // Truncate to 28 bits removing the 4 most significant bits
    member_id = hash_as_int & 0x0FFFFFFF;
    

    In the case of member name "color" we would have:

    NameHash = { 0x70, 0xDD, 0xA5, 0xDF } 
    hash_as_int = 0x70DDA5DF
    member_id  = 0x00DDA5DF
    

    Assuming we have M_FLAG = 1, LC = 1, we would have:

    EMHEADER1 = 0x90DDA5DF
    

    EMHEADER1 is then serialized on the wire using Little Endian format (as specified by the TypeObject serialization) so the bytes on the wire would end up being:

    {0xDF, 0xA5, 0xDD, 0x90} 
    


    Alternatively (currently favored by Task Force)

    We could define the transformation of NameHash to MemberId using LittleEndian. This will save the byte swap done at serialization time. An also save the initial on in LittleEndian machines (which are the most common). So this seems a more optimized approach.''

    In this case member name "color" we would have:

    NameHash = { 0x70, 0xDD, 0xA5, 0xDF } 
    hash_as_int = 0xDFA5DD70
    member_id  = 0x0FA5DD70
    

    If we go with this we need to change the examples in section 7.6.2.3.3 'TypeLookup Types and Endpoints'

    NameHash("getTypes") = {d3, 52, 82, d1}
    NameHash("getDependencies") = {31, fb, aa, 35}
    Also change the example to be unsigned long:

    const unsigned long TypeLookup_getTypes_Hash = 0x018252d3; // @hashid("getTypes")
    const unsigned long TypeLookup_getDependencies_Hash = 0x05aafb31; //@hashid("getDependencies"); 
    
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Inconsistencies and missing items

  • Key: DDSXTY13-1
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 7.2.3, Table 12 in the rows for "Collection Types", "String Types", and "Primitive Types" should add that "For these types the extensibility kind has no effect in the type matching."

    In Section 7.2.3, Table 12 the row for "Bitmask" says it is always final. This seems limiting, should be like Enum and allow "final" or "appendable"

    In figure 11, 12 and the XSD it shows extensiblity_kind=FINAL for enumerations. This is wrong and inconsistent with 7.2.3.

    The XSD does nor allow setting the "extensibilty" for the "enumDecl". It should.

    In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.
    Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.

    In section 7.3.4.4 'Minimal TypeObject' the last paragraph starts with "The complete TypeObject" it should start with "The minimal TypeObject"

    In Annex B in the IDL comment for AppliedBuiltinMemberAnnotations refers to “@hash_id” as opposed to “@hashid”, which is the actual annotation name. Every reference to “@hash_id” should be modified to refer to "@hashid."

    Typo in section 7.2.3 (Type Extensibility and Mutability) it says "APENDABLE" instead of "APPENDABLE"

    Typo in XSD says "include2" instead of "include"

  • Reported: DDS-XTypes 1.1 — Thu, 16 Mar 2017 00:38 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Perform the corrections listed in the issue description

    Perform the corrections listed in the issue description

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Clarify which of the options bits are set to indicate padding bytes

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    As the spec is currently written, section 7.6.2.1.2
    'Use of the RTPS Encapsulation Identifier', it is ambiguous as to which bits are used to encode the padding bytes.

    RTPS 2.4 is redefining the options field to be an array of two octets rather than a ushort. So XTypes should specify that the lower-order two bits of options[1] are used to encode the number of padding bytes.

  • Reported: DDS-XTypes 1.2 — Wed, 7 Mar 2018 01:49 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Modify 7.6.2.1.2 'Use of the RTPS Encapsulation Identifier'

    Modify 7.6.2.1.2 'Use of the RTPS Encapsulation Identifier' to indicate that the options field is octet[2] and that the bits using for padding are the least significant bits of the second byte:

    0...2...........8...............16..............24..............32 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |   representation_identifier   |               |            X X| 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Endianess bit in DHEADER causes innefficiencies

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The presence of a bit indicating the endianess in the DHEADER causes serious inefficiencies in the serialization.

    • When mutable encapsulation is used, the length of the member can be shared between the MemberHeader and the MemberSerialization in the case where the MemberSerialization starts with a length. This would be the case for strings and octet sequences. If the DHEADER did not have the EndianessBit then this optimization would also apply to the @appendable members which is a very common use-case.
    • The processing of the Endianess bit (pack/unpack) and check takes CPU time. This would be avoided if the Endianess bit is not present.

    The reason why the Endianess Bit was put was to support embedding serialized data inside other serialized data even if the pieces came from different endianess. This is not a common use-case. Supporting this edge case is not worth hurting the performance of the common case.

    The proposal is to remove the Endianess Bit from the DHEADER.

  • Reported: DDS-XTypes 1.2 — Thu, 6 Sep 2018 02:10 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Remove E_FLAG from DHEADER

    Redefine the DHEADER used for Appendable and Mutable types to only contain the length of the serialized object that follows (O.ssize).

    This affects the following parts of the specification:

    • Table 39 ('Functions operating on objects and types'. The entry for DHEADER shall be changed to just say DHEADER(O) = O.ssize
    • Section 7.4.3.4.1 'Delimiter Header (DHEADER)' remove mentions of the
      E_FLAG.
    • Section 7.4.3.5.3 'Complete Serialization Rules'. Replace "DHEADER(O, <E>)" with "DHEADER(O)" this affects rules (9), (12), (15), (21), (27), (30).
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Annotation for denoting topic types

  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    In order to use an IDL type as a topic type, some additional methods are required to be generated (such as methods for creating DataReaders and DataWriters).

    Implementations have invented their own mechanisms in this area:

    • One product might support the notion that by default all structured types can be used as topic types, defining a mechanism to selectively switch off that assumption
    • Another product might require a pragma to be used for switching on the additional code generation for topic types

    A built in annotation should be added for distinguishing topic types from non topic types.

  • Reported: DDS-XTypes 1.2b1 — Mon, 12 Feb 2018 06:46 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Introduce a @DDSTopic annotation that allows marking DDS Topic Types

    Define a new annotation that can be used to indicate that certain types are intended to be used as DDS Topic Types.

    There are some related precedents:


    DDS-RPC

    This @DDSTopic annotation parallels the @DDSService annotation defined in DDS-RPC. The definition is of @DDSService

    @annotation DDSService {
        string name default "";
    };
    

    Note that DDS-RPC also defines the following annotations:

    module dds { module rpc {
    @annotation DDSRequestTopic {
        string name;
    };
    @annotation DDSReplyTopic {
        string name;
    };
    
    };};
    

    IDL 4.2
    This specification which was released after DDS-RPC introduced a new notation for marking services:

    @annotation service {
    string platform default "*";
    };
    

    In IDL42 there are three pre-defined values of for the platform:

    • "CORBA" indicates that the service should be made accessible via CORBA.
    • "DDS" indicates that the service should be made accessible via DDS.
    • "*" (an asterisk) indicates any platform. This is the default value.

    So a definition that follows what was done in DDS-RPC could be:

    @annotation DDSTopic {
        string name default "";
    };
    

    Whereas a definition that follows what was done in IDL 4.2 could be:

    @annotation topic {
       string platform default "*";
    };
    

    Or some other name instead of "topic", perhaps "message" if we consider it sufficiently generic:

    Note that all MQTT (http://mosquitto.org/man/mqtt-7.html), Amazon Pub-Sub (https://aws.amazon.com/pub-sub-messaging/), and Google PubSub (https://cloud.google.com/pubsub/docs/overview) use the concept of messages sent to a Topic.


    If we used a @topic definition in IDL and we wanted to be able to specify the Topic name would need to combine it with another annotation (in DDS-XTYPES, not IDL) to do this. For example @DDSTopicName. So finally we would have:

    IDL4 -> @service , @topic. These allow specifying the platform, e.g. @service("DDS") or @topic("DDS"). If not parameter is specified the default is @service("*"), @topic("*").
    Then in DDS-RPC we have @DDSServiceName("MyService"), @DDSRequestTopic("MyServiceRequest"), @DDSReplyTopic("MyServiceReply")
    Ans in DDS-XTYPES we have @DDSTopicName("MyTopic").


    Alternatively we could try to eventually push all this into the IDL annotations. For example:

    @annotation service {
         string platform default "*";
         string name default "";
         string request_topic default "";
         string reply_topic default "";
    };
    
    @annotation topic {
         string platform default "*";
         string name default "";
    };
    

    So for now we could add @topic to the DDS-XTYPES and push it to IDL4 later.

    How would annotations with parameters appear in XML? Is it legal to do something like:

    <struct name="Shape"  topic.name="Square" topic.platform="DDS">
        <member name="color" type=string"/>
     </struct>
    
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Typographical corrections and minor rewordings

  • Key: DDSXTY13-5
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    > 2.2.2 Basic Network Inteoperability Profile

    • "Interoperability"

    > 7.2.3 Type Extensibility and Mutability
    > [...]
    > • A type may be APENDABLE,

    • "APPENDABLE"

    > [...]
    > It is summarized more enerally in Table 12.

    • "generally"

    > 7.2.4.4.1 Assignability of Equivalent Types
    > If two types T1 and T2 are equivalent according to the MINIMAL relation (see Section 7.3.4.7),
    > then thery are mutually assignable,

    • "they"

    > Table 15 – Definition of the is-assignable-from relationship for primitive types
    > [...]
    > UINT64_TYPE
    > BITMASK_TYPE if and only if
    > T2.bound is between 33vand
    > 64, inclusive.

    • "between 33 and 64"

    > Table 20 – Alternative Type Representations
    > [...]
    > XSD [... 2nd column]
    > [...] No direct support for many of the
    > contructs (e.g keys) or the types in
    > the type model

    • "constructs"

    > 7.3.4.6.2 Hash TypeIdentifiers
    > Some TypeIdentifiers include within (directly or indirectly) hashes of one of mre
    > TypeObjects.
    Phrase is unclear, please reword.

    > 7.3.4.6.4 Indirect Hash TypeIdentifiers
    > These are the HASH [...] using a hash
    > TypeIdentifiers . They are distinghished byt:

    • "They are distinguished by:"

    > 7.4.1.1.1 Primitive types
    > [...]
    > • An endianness byte swap shall be performed in case the native system endianness is dif-
    > ferent from the one currently configured in the XCDR stream (XCDR.cendien).

    • "XCDR.cendian"
  • Reported: DDS-XTypes 1.2b1 — Sun, 10 Sep 2017 19:05 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Correct the typos

    Perform the typographical corrections indicated in the issue description.
    Note that some of the issues indicated in the description were already resolved as part of the editorial corrections performed by OMG editors. This issue addresses the ones that were not caught in that step.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Clarify valid ranges of memberIDs

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.5.2.5 (MemberId) states that

    The type MemberId is an alias to UInt32 and is used for the purpose of representing the ID of a member of a structured type.

    However it is clear from the serialization rules in 7.4.3.4 and specifically the definition of EMHEADER1 in table 39:

    EMHEADER1 = (M_FLAG<<31) + (LC<<28) + M.id 
    
    Where:
    M_FLAG is the value of the Must Understand option for the member
    LC is the value of the Length Code for the member.
    

    That MemberId are restricted to a 28-bit range. This should be clarified in the specification.

    Furthermore the specification should make it clear that the M_FLAG is not introducing a separate "space" of member IDs. So a type cannot have two members with the same value of the 28-bit memberID even if one has M_FLAG=1 and the other M_FLAG=0.

    Additionally in section 7.4.1.2.1 (Interpretation of Parameter ID Values) where it talks about PID_EXTENDED it states:

    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. The flags occupy the 4 most significant bits of the UINT32 value. The flags are combined with the memberId as shown below:
    FLAG_1 = 0x80000000
    FLAG_2 = 0x40000000
    FLAG_3 = 0x20000000
    FLAG_4 = 0x10000000
    eMemberHeader = FLAG_1 + FLAG_2 + FLAG_3 + FLAG_4 + memberId

    This text does not specify the reserved bit for the "FLAG_MUST_UNDERSTAND" and also in the case this is used for RTPS Discovery, the mapping for the "FLAG_IMPL_EXTENSION".

    For compatibility with existing deployed systems the specification should state that FLAG_1 is the FLAG_IMPL_EXTENSION and FLAG_2 is FLAG_MUST_UNDERSTAND.

  • Reported: DDS-XTypes 1.2 — Fri, 6 Jul 2018 00:09 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    *Add a note to 7.5.2.5 'MemberId' indicating the range of member IDs. *

    In section 7.5.2.5 (MemberId) add a reference to 7.2.2.4.4.4.4.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Setting of @default with @optional members

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The default value of an member defined with @optional is "not set".

    However it is possible to also apply the @optional annotation. In this situation should the value specified in the @default override the "not set" default?

    For example if MyStruct is specified as:

    @mutable
    struct myStruct {
      long m1;
      @optional @default(2) long m2;
    }
    

    Would the default value of m2 be "not set" or 2?

    At first glance it would seem that @default should override since if that was not the desired behavior then the user could just as well omit it. On the other hand, there seems to be a bit of ambiguity. Imagine m2 is not set by the sender, would the receiver then get "not set" or 2. If it gets 2, then how would a user ever detect the lack of m2 being set which is one of the goals of optionality.

  • Reported: DDS-XTypes 1.2 — Tue, 3 Jul 2018 15:27 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Do not allow a @default on an @optional member

    The @optional annotation is incompatible with the @default annotation. When both are set it should cause an error or at least a warning that @default is ignored.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Reseting the alignment after Encapsulation Header

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    RTPS version 2.3 (see https://issues.omg.org/browse/DDSIRTP23-63) specifies that the alignment should be reset after the encapsulation header.

    Consequently the serialization rules in 7.4.3.5.3 should be updated to include this.
    Specifically in rule (1) after:

    << PUSH( MAXALIGN = MAXALIGN(<eversion>) )

    We should add:

    << PUSH( ORIGIN=0 )

  • Reported: DDS-XTypes 1.2 — Fri, 20 Apr 2018 11:45 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    In section 7.4.3.5.3, rule (1) add alignment reset

    Perform the change suggested in the issue description.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Inheritance rules not sufficient regarding keys and memberID assignment

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    XTYPES should specify that if a type declares key members then derived types cannot add additional key members.

    The reason is that the derived type will never be compatible with the base type according to the compatibility rules so there is no purpose on allowing that inheritance which would mislead the user.

    Semantically it seems that extending the key breaks the substitution principle where a derived class can be used in place of a base-class anywhere. If we allowed key extension two different objects could appear to be the same when viewed as a "base class"

    Additionally in section 7.3.1.2.1.1 'Member IDs' there is no mention of how inheritance impacts the automatic assignment of member IDs.

  • Reported: DDS-XTypes 1.2 — Fri, 20 Apr 2018 13:02 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Specify rules for inheritance

    The rules for inheritance could be added to a subsection following *7.2.2.4.4 'Aggregated Types'*. This new subsection should state that:

    Structure types can inherit from other structure types as long as:

    • The derived structure either has same extensibility kind or leaves the extensibility kind unspecified
    • The derived type does not have a member with the same name or the same memberId as the base type or any of the ancestor types (i.e. recursively applying this rule to the parent)
    • The derived type does define any key fields. Is this really what we want to do. Will it break some definition where the "base type" is just being reused as a "header"? All to think about it and come up with a preferred approach.

    Also mention in 7.3.1.2.1.1 'Member IDs' that the memberId are continuing from the base class.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Organization of section 7.2.2.4.4 is confusing

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.2.2.4.4 'Aggregated Types' has a confusing organization of its sub-sections. It mixes at the same level description of common aspects of Aggregated types (e.g. members names, types, properties like being optional etc). With the classification of 'Aggregated Types' into "Structures' and 'Unions'.

    Moreover the concept of "member index" is not explicitly defied even if it appears in the figures and UML model. The text does talk about a "declaration order" for members but does not tie it to the "member_index" concept.

    It would be better if the subsections were reorganized. Rather than:

    7.2.2.4.4.2 Structure Types
    7.2.2.4.4.3 Union Types
    7.2.2.4.4.4 Member IDs
    7.2.2.4.4.5 Members That Must Be Understood by Consumers
    7.2.2.4.4.6 Optional Members
    7.2.2.4.4.7 Key Members

    It would be better if it was:
    7.2.2.4.4.1 General
    7.2.2.4.4.2 Structure Types
    7.2.2.4.4.3 Union Types
    7.2.2.4.4.4 Members of an Aggregated Type
    7.2.2.4.4.4.1 Member Name
    7.2.2.4.4.4.2 Member Type
    7.2.2.4.4.4.3 Member Index
    7.2.2.4.4.4.4 Member ID
    7.2.2.4.4.4.5 Must Understand Members
    7.2.2.4.4.4.6 Optional Members
    7.2.2.4.4.4.7 Key Members

    This reorganization should be applied before other issue resolutions that affect the section as they would benefit from the more logical section numbering.

  • Reported: DDS-XTypes 1.2 — Wed, 7 Nov 2018 18:21 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Reorganize section 7.2.2.4.4 as suggested in the issue description

    Apply the suggested reorganization

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Remove Endianness bit from DHEADER

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Redefine the DHEADER used for Appendable and Mutable types to only contain the length of the serialized object that follows (O.ssize).

    This affects the following parts of the specification:

    • Table 39 ('Functions operating on objects and types'. The entry for DHEADER shall be changed to just say DHEADER(O) = O.ssize
    • Section 7.4.3.4.1 'Delimiter Header (DHEADER)' remove mentions of the
      E_FLAG.
    • Section 7.4.3.5.3 'Complete Serialization Rules'. Replace "DHEADER(O, <E>)" with "DHEADER(O)" this affects rules (9), (12), (15), (21), (27), (30).
  • Reported: DDS-XTypes 1.2 — Tue, 25 Sep 2018 02:38 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.3
  • Disposition Summary:

    Close because it duplicates DDSXTY-29

    Duplicates DDSXTY-29

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Ambiguity in Table 9 and Obsolete language in section 7.3.1.2.1.10

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The first paragraph 7.3.1.2.1.10 (Default Literal for Enumeration) says:

    Normally the default value for an object of a type is pre-defined based on the generic rules based on the characteristics of the type. For example, for an integer it would be the value zero and for an enumeration it is the literal with the lowest member ID.

    This language is obsolete. In XTYPES 1.2 Enumerated types are not considered to have memberId. Only AggregatedTypes have memberIds.

    Instead this paragraph should reference Table 9 (Table 9 – Default values for non-optional members). Which in the case of the enumeration says it is the first value in the enumeration.

    In addition, Table 9 (Default values for non-optional members) on the row for Enumerations says the default is:

    The first value in the enumeration.

    This is a bit ambiguous. Most likely it should be interpreted as the first literal that appears in the enumeration. But the word "value" may be interpreted by some as meaning the "lowest value" of any literals in the enumeration. It shuld be reworded to avoid confusion.

  • Reported: DDS-XTypes 1.2 — Sat, 22 Sep 2018 00:03 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Update Table 9 and section 7.3.1.2.1.10

    Update the text as suggested in the issue description.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Compatibility of Enum should be allowed even if there is just one common literal

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The compatibility rule for ENUM_TYPE Table 18 'Definition of the is-assignable-from relationship for bitmask and enumerated types' states:

    • If extensibility is final the set of literals should be identical. Otherwise the two types should have at least one other literal (in addition to the default one) in common.

    This will break types that were compatible in xtypes v1. Namely enumerated types that just had one literal in common.

    Defining enumerations with a single literal which is then expanded is a common patten in a surprising number of applications. So this change is quite disruptive.

    The proposal is to not require the minimum of two literals in common. In other words change the quoted paragraph to:

    • If extensibility is final the set of literals should be identical.

    In addition some people dislike the fact that we make enums that have different default values incompatible. This will make two enums like the ones shown below incompatible. There is a strong opinion that this will break a lot of existing systems:

    enum Enum1 {
       @value(1) RED,
       @value(2) BLUE
    };
    
    enum Enum2 {
       @value(2) BLUE,
       @value(1) RED
    };
    
    enum Enum3 {
       @value(2) BLUE,
       @value(1) RED,
       @value(0) ORANGE
    };
    
    

    So the proposal is to also remove the requirement:

    • The default literal has the same value.

    Lastly there question/request to have the TypeEnforcementPolicy attribute ignore_member_names apply to Enum as well... Alternatively it could be a different policy attribute, e.g. ignore_enum_literal_names.
    We have several customers that have this requirement.

  • Reported: DDS-XTypes 1.2 — Wed, 26 Sep 2018 03:39 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Modify compatibility for enum types and non-final extensibility

    Apply the changes suggested in the issue description.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Union discriminator value without associated member

  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    The DDS-XTypes 1.2-beta1 document section 7.2.2.4.4.2 (Union Types) on page 34 first paragraph states:

    > [...]
    > (Note that it is not required for every potential discriminator value to be
    > associated with a member.)

    Supporting this, 7.4.3.5.1 (Notation used for the match criteria) on p.121 states:

    > O : UNION_TYPE An object "O" of a Union type as defined in 7.2.2.4.4.2
    > [...]
    > * O.selected_member is the member of the union selected
    > based on the value of the discriminator. Note that certain
    > discriminator values may select no member.

    However, 7.4.1.2.3 (Omission and Reordering of Members of Aggregated Types) on page 110 third para states:

    > Because union members are identified based on a discriminator value,
    > the value of the discriminator member must be serialized before the
    > value of the current non-discriminator member.
    > Neither member value may be omitted.

    I suggest replacing "Neither member value may be omitted" by:

    " The discriminator value may not be omitted.
    If the discriminator value has an associated member then the member value may not be omitted. "

    Section 7.5.2.11.6 (Operation: get_item_count) on page 185 states:

    > The "item count" of the data depends on the type of the object.
    > * If the object is of a union type, return the number of members in the
    > object. This value will always be two: the discriminator and the current
    > member corresponding to it.

    I suggest replacing the last sentence by:

    " This value will be two if the discriminator value has a corresponding member. It will be one if the discriminator value has no corresponding member. "

  • Reported: DDS-XTypes 1.2b1 — Wed, 29 Nov 2017 16:12 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Modify the 7.4.1.2.3 description of union serializarion

    Indicate that in the case of a union the only mandatory thing to serialize is the discriminator. The member may be omitted if no branch is selected.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Provide a more efficient serialization for short strings and sequences

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    XCDR serialization rules for strings and sequences serialize the length as an uint32 ahead of serializing each of the elements.

    For short strings and sequences this can be a significant overhead. For example a 4 element sequence of octets would use 4 bytes for the sequence length and 4 bytes for the sequence content. That is 100% overhead. Worse since the serialized uint32 length must be serialized at a 4-byte offset, in some cases 3 additional padding bytes would be required. This would result on 7 bytes of overhead for 4 bytes of payload, or 175% overhead!!

    It would be better is short sequences, that is those whose maximum length is less than 255 could be serialized using an uint8 length instead of a uint32. With this the overhead of the previous example would be 1 byte (or 25%).

    An additional optimization would be to just serialize the string characters without the terminating NUL since this information is redundant with the length.

    This encoding would affect type compatibility in that a "short" sequence would not be compatible with a longer one. This is different from the current situation where string/sequence length would not affect compatibility. With the new encoding short strings would be compatible with each other (regardless of their length) and likewise long strings would also be compatible with each other (regardless of length) as well as compatible with unbounded ones.

    So therefore we would need an annotation to indicate we want to serialize it as a short string... Perhaps we could reuse @bit_bound. For example:

    struct ShapeType {
        @bit_bound(8) string<32> color;
        long x;
        long y;
    };
    

    Disadvantage is that the only valid values when applied to strings/sequences would be @bit_bound(8) and @bit_bound(32).

    Alternatively we could also a new annotation like @compact, @pack, @short, @small, ...

  • Reported: DDS-XTypes 1.2 — Wed, 17 Jan 2018 11:29 GMT
  • Disposition: Deferred — DDS-XTypes 1.3
  • Disposition Summary:

    Defer until we can determine weather the optimization is worth the added complexity

    The RTF thinks is is best to wait and see if the need for this kind of optimization is sufficient to justify the added complexity to the user, and the implementation

    he concern is that this effectively introduces new sets of incompatible collection types:
    "short" strings are now incompatible with regular strings
    "short" sequences are incompatible with regular sequences,
    and so on.

    Note that two strings with a maximum length of say 20 would be incompatible if one is defined as a "sort" string and the other not. The one not defined as a "short" string would be compatible with (non-short) strings of any length. The one defined as short with short strings of any length.

    This will increase the complexity to the user who must now decide whether their strings (and sequences) should be defined as short or not to save some bytes, but then live with the consequence that it will not be possible to extend them...

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Restrictions on MAP key element type should include ENUM

  • Key: DDSXTY13-6
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    DDS-XTypes 1.2 section 7.2.2.4.3 (Collection Types) on page 30 bottom states:

    > * Element type: The concrete type to which all elements conform. (Collection Elements
    > that are of a subtype of the element type rather than the element type itself may be
    > truncated when they are serialized into a Data Representation.)
    > In the case of a map type, this attribute corresponds to the type of the value elements.
    > Map types have an additional attribute, the key element type, that indicates the type of the
    > may key objects.

    I believe there is a typo in "type of the may key objects" - drop the word "may" ?

    The paragraph continues:

    > Implementers of this specification need only support key elements of
    > signed and unsigned integer types and of narrow and wide string types; the behavior of
    > maps with other key element types is undefined and may not be portable.

    Is there a particular reason why enums were excluded from the supported key types?

  • Reported: DDS-XTypes 1.2b1 — Fri, 15 Sep 2017 13:51 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.3
  • Disposition Summary:

    Corrections were already applied in the formal document

    The typo mentioned in the description was already corrected in the formal DDS-XTYPES 1.2 document.

    Allowing enum to be used as key discriminator would introduce problems with type interoperability or data reception. Given that a similar behavior can be achieve at the application level (using the ordinal value associated with each enumeration literal) it seems better to leave the specification with the existing limitation.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Redefinition of the LC=6 and LC=7

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently LC=6 indicates the length is multiplied by 2 and LC=7 indicates it should be multiplied by 4.

    It would be better if LC=6 indicated the length is multiplied by 4 and LC=7 indicated it should be multiplied by 8.

    The reason is that members of length 8 (INT64) and DOUBLE are far more common that members of length 2 (INT16 and CHAR16).

  • Reported: DDS-XTypes 1.2 — Thu, 6 Sep 2018 02:21 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Change the interpretation of LC=6 and LC=7

    Change de interpretation of the Length Code (LC) for values LC=6 and LC=7. The new interpretation shall be:

    • LC = 6 = 0b110 indicates serialized member length is 4*NEXTINT
    • LC = 7 = 0b111 indicates serialized member length is 8*NEXTINT

    This impacts only de LC definitions that appear in section 7.4.3.4.2 'Member Header (EMHEADER), Length Code (LC) and NEXTINT'

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Computation of KeyHash (7.6.7 Interoperability of Keyed Topics) needs additional detail

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.6.7 (Interoperability of Keyed Topics) states that:

    As described in [ RTPS ] Clause 9.6.3.3, “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 such that key member values shall be serialized in the ascending orders of their member IDs. For calculation of KeyHash for mutable types, the key members shall be serialized without any parameter encapsulation.

    This statement does not explicitly say what to do about the DHEADER.

    The section should be amended to state that the DHEADER should also not be serialized for the purpose of the KeyHash computation. This is consistent with the stated "design rationale" of making the computation should be platform independent. The DHEADER could create an ambiguity as it allows to specify an endianess which would result in different hashes if different endianess are used.

    In addition it would be desirable to include examples where the types containing the keys are @appendable and @mutable. E.g.

    @mutable
    struct MyKeyedStruct {
        @key string name;
        @key long id;
        @long x;
        @long y;
    };
    

    Also we there should be an examples where the key fields themselves are declared as structures with extensibility @appendable or @mutable. E.g.

    @mutable
    struct MyOuterKeyedStruct {
        @key MyKeyedStruct inner_struct;
        @key long  another_key;
        @long z;
    };
    
  • Reported: DDS-XTypes 1.2 — Wed, 5 Sep 2018 02:08 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.3
  • Disposition Summary:

    Subsumed by DDSXTY13-22

    This issue has already been addressed by DDSXTY13-22

  • Updated: Tue, 8 Oct 2019 17:55 GMT

The definition of ReliabilityQosPolicyKind in Annex D is inconsistent with RTPS

  • Key: DDSXTY13-8
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In the RTPS spec the values of ReliabilityQosPolicyKind are defined to be:
    BEST_EFFORT_RELIABILITY_QOS = 1
    BEST_EFFORT_RELIABILITY_QOS = 2

    However, in appendix D the ReliabilityQosPolicyKind is defined as:

    enum ReliabilityQosPolicyKind {
        BEST_EFFORT_RELIABILITY_QOS,
        RELIABLE_RELIABILITY_QOS
    };
    

    To match what the RTPS specifies this should be modified to:

    enum ReliabilityQosPolicyKind {
        @value(1)  BEST_EFFORT_RELIABILITY_QOS,
        @value(2)  RELIABLE_RELIABILITY_QOS
    };
    
  • Reported: DDS-XTypes 1.2 — Tue, 5 Dec 2017 18:07 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.3
  • Disposition Summary:

    Duplicates DDSXTY13-9

    Duplicates DDSXTY13-9

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Union default values (Table 9)

  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In Table 9 " Default values for non-optional members".

    For type kind UNION_TYPE, the default value may require the discriminator to be set to the "lowest value associated with any member", however the "lowest" relation isn't defined for all possible discriminator types.
    Boolean: use false (based on Table 9)
    Byte: undefined (based on Table 3)
    Char<N>: undefined
    UInt<N>: well defined
    Int<N>: need to define/clarify for negative numbers
    Enum: treat as Int32 per Table 4

  • Reported: DDS-XTypes 1.2b1 — Thu, 14 Dec 2017 20:17 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Modify the definition of the UNION_TYPE default value

    In table 9 set the union according to these rules:

    • Set the discriminator to the default value for the discriminator type
    • If that discriminator value does not select a branch, then there is nothing else to set
    • If that discriminator value selects a branch, then set the selected member to the default value for that corresponding member type

    Note that even if there is no explicit "default" brach, it is still possible to set discriminator to a value they is not covered in the explicit cases. This selects the so-called "implicit" default which has an empty branch.

  • Updated: Tue, 8 Oct 2019 17:55 GMT

Explicitly define the values for ReliabilityQosPolicyKind

  • Key: DDSXTY13-9
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The RTPS Spec defines BEST_EFFORT and RELIABLE_RELIABILITY as:
    #define BEST_EFFORT 1
    #define RELIABLE 2 (as of RTPS2.4, previously it was defined as 3)

    The XTypes Spec should align itself with these values by defining ReliabilityQosPolicyKind as follows in Annex D - DDS Built-in Topic Data Types:

    enum ReliabilityQosPolicyKind {
        BEST_EFFORT_RELIABILITY_QOS = 1,
        RELIABLE_RELIABILITY_QOS = 2
    };
    
  • Reported: DDS-XTypes 1.2 — Fri, 8 Dec 2017 17:55 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    Update the definition of enum ReliabilityQosPolicyKind in Annex D

    Modify the definition of enum ReliabilityQosPolicyKind in Annex D to match what is shown below:

    enum ReliabilityQosPolicyKind {
        @value(1) BEST_EFFORT_RELIABILITY_QOS,
        @value(2) RELIABLE_RELIABILITY_QOS 
    };
    
  • Updated: Tue, 8 Oct 2019 17:55 GMT

Users should have more control over when and how types match

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The type assignability rules aim to make evolving types simple and intuitive. However, there are many cases in which the rules may not match a user's needs. For example, it may or may not be desirable for the member names to be taken into account during type assignability or it may be useful to disallow types from matching solely based on the type name in the absence of type information.

    Therefore we are proposing that the following behaviors are added to the TypeConsistencyEnforcementQosPolicy:

    1. Provide a way to specify to only match readers/writers that you have the TypeObject so that you can ensure type compatibility.
    2. Provide a way to ignore member names, sequence bounds and string bounds
    3. Provide a way to prevent type widening

    And that the following builtin annotation be added:
    @hash id("old_member_name")
    When using auto member ids, the member id is assigned to be the 4-byte hash of the member name. If a user wants to change the name of the member in another version of the type, the member id will change. This annotation will solve that situation by allowing the user to obtain the hash of the old member name as the member id for the member with a different name in the new version.

  • Reported: DDS-XTypes 1.1 — Thu, 22 Dec 2016 19:26 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Add new fields to the TypeConsistencyEnforcementQosPolicy and new @hash_id annotation

    Allow users to have more control over type evolution and the type assignability rules by adding fields to the TypeConsistencyEnforcementQosPolicy and a @hash_id annotation

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Computing the TypeObject and TypeId for recursive types

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    A recursive type is one that refers to itself either directly or indirectly. These types are useful to represent dynamic data structures such as trees. For example:

    struct Node;
    struct Node {
        long data;
        @external @optional Node left_child;
        @external @optional Node right_child:
    };
    

    The children are marked @external so that the generated code in languages like C and C++ that can hold object by value uses a reference and therefore does not complain about "incompletely defined symbols"

    The children are marked @optional so that the recursive type can be terminated.

    There is no fundamental problem in supporting these types in the XTYPES type system. Except that the algorithm used to create the TypeObject and compute the TypeId would fail because the type object of an aggregate type requires knowledge of the TypeIdentifiers (and hence TypeObjects) of all the member types and the recursion creates a cyclic-dependency on this.

    Even if this not resolved in RTF 2.2 we need a plan so that we do not break interoperability in the future.

  • Reported: DDS-XTypes 1.1 — Tue, 10 Jan 2017 15:14 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    This is addressed by DDSXTY12-100

    Issue DDSXTY12-100 modifies the definition of TypeObject and updates the algorithm to compute TypeIdentifiers from the TypeObjects.

    The updated algorithm can handle mutually dependent types and "recursive" types. Therefore this issue is being merged into DDSXTY12-100.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

UML Model is not consistent with document and missing types

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This changes are needed to align the XTYPES model with IDL4. Specifically with regards to annotations.

    In IDL4 it is possible to annotate type declarations, members, and elements in a collection as in:

    @MyAnnotation(3)
    struct MyStruct {
        @MemberAnnotation  long l_member;
        sequence< @ElementAnnotation long, 55>   seq_member;
    };
    

    Union discriminators can also be annotated and so can members, but not the case literals:

    @MyAnnotation(3)
    union MyUnion switch ( DiscriminatorAnnotation(44)  long)  {
        case 1:
           @MemberAnnotation  long  l_member;
        default:
            sequence< @ElementAnnotation long, 55>   seq_member;
    };
    

    It is also possible to annotate enumeration, bitmask and bitset members.

    @MyAnnotation(3)
    bitmask MyBitmask{
        @position(2)  flag1;
    };
    

    Annotation are also permitted in the “related type” for a typedef:

    typedef  @max(23) long  MyLong;
    typedef  sequence<@external long>  LongPtrSeq;
    

    Another issue is that in the new XTYPES we are no longer requiring that all types are named. So that the inheritance of Type from NamedElement is not what we want.

    Currently we use NamedElement model both the name of a type as well as the name of a member (structure, union), name of a bitflag, module, and enum literal.

    Those are things we want to annotate. But we also want to annotate element of a collection as well as the discriminator of unions which have no name.

  • Reported: DDS-XTypes 1.1 — Fri, 20 Jan 2017 10:49 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Update UML Model to align it with IDL4

    This changes are needed to align the XTYPES model with IDL4. Specifically with regards to annotations.

    In IDL4 it is possible to annotate type declarations, members, and elements in a collection as in:

    @MyAnnotation(3)
    struct MyStruct {
        @MemberAnnotation  long l_member;
        sequence< @ElementAnnotation long, 55>   seq_member;
    };
    

    Union discriminators can also be annotated and so can members, but not the case literals:

    @MyAnnotation(3)
    union MyUnion switch ( DiscriminatorAnnotation(44)  long)  {
        case 1:
           @MemberAnnotation  long  l_member;
        default:
            sequence< @ElementAnnotation long, 55>   seq_member;
    };
    

    It is also possible to annotate enumeration, bitmask and bitset members.

    @MyAnnotation(3)
    bitmask MyBitmask{
        @position(2)  flag1;
    };
    

    Annotation are also permitted in the “related type” for a typedef:

    typedef  @max(23) long  MyLong;
    typedef  sequence<@external long>  LongPtrSeq;
    

    Another issue is that in the new XTYPES we are no longer requiring that all types are named. So that the inheritance of Type from NamedElement is not what we want.

    Currently we use NamedElement model both the name of a type as well as the name of a member (structure, union), name of a bitflag, module, and enum literal.

    Those are things we want to annotate. But we also want to annotate element of a collection as well as the discriminator of unions which have no name.

    Modifications to the UML model

    The UML model needs an AppliedAnnotation class that models the application of annotations to some other classifier.

    Also NamedElement should not be modeled as a “base class” but rather as something that certain classifiers have. So it should be a “has-a” relationship. That would allow some types (e.g. anonymous types) to not have a name.

    String should not inherit from Collection. There should be a StringType that is specialized by String8 and String16. StringType would be a direct child of Type, peer to PrimitiveType.

    There should be a EnumeratedType peer of PrimitiveType. It should have Enumeration and Bitmask as specializations.

    Bitset should be added as another specialization of Aggregation.

    In addition:

    • Create an association between Aggregation and NamedElement. This has cardinality “1”. Every Aggregation type has a name.
    • Create an association between Collection and NamedElement. This has cardinality “0..1”. Collection types can be named or anonymous.
    • Create an association between Alias and NamedElement. This has cardinality “1”. Alias types always have a name.
    • Add an association between ConstructedType and NamedElement. It should have to be “0..1” to capture the possibility for anonymous collections.
    • Module, EnumerationLiteral, Bitflag, Member, and Bitfield would also have a “has-a” relation to NamedElement with cardinality “1”.
    • Model the annotations on collection element and union discriminator.
    • Union Discriminator requires a separate class. Currently it is modeled as a “member” but that is odd (e.g. it is unnamed, has hard-coded memberID) better to model it separately.
    • Change NamedElement to ScopedIdentifier.

    Enhance model for Annotations
    Currently Annotation specializes Aggregation type. This is wrong in several ways.
    Al constructed types can be annotated. But Annotations cannot have annotations.
    It does make sense to talk about the extensibility kind of an annotation. Nor about the type compatibility/assignability.

    Many associations to type (e.g. a structure member has a type) do not make sense if the “type” is an annotation.

    The only thing from Type is that they can have a type object.

    Annotations should not be modeled as types. They should not specialize “Type” they should be their own thing. Basically we define a AnnotationDeclaration an AppliedAnnotation (and AnnotationParameter). This can follow the TypeObject model.

    Then section 7.2.2.3.6 “Annotation Types” can be moved to a higher level. Say 7.2.2.6 after :”Try Construct Behavior”

    Also in the XTYPES it says (in section 7.2.2.3.6) that annotations can inherit from other annotations. However the IDL grammar 7.4.15 does not support annotation inheritance so we should get rid of that in the XTYPES.

  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Fix a Number of Issues in Final Document


XTypes impacts on IDL and language mappings; optional conformance

  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Since XTypes changes how IDL and language mappings work, determine if an XTypes implementation can still be conformant (perhaps using optional conformance) if certain features are not implemented – for example external/shareable types.

    There are many OMG specs listed in section 3 "Normative References." XTypes should be explicit about which of these are required dependencies, which are optional, and which sections of those specs are important for XTypes.

  • Reported: DDS-XTypes 1.1 — Fri, 18 Nov 2016 16:27 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    *Update the conformance section *

    Update the conformance chapter to reflect and include the new sections in the spec

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Improving Extensible Types

  • Legacy Issue Number: 18146
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Extensible Types do not support monotonic extensions of nested struct types. Adding support for monotonic extensibility of nested structures is straight-forward and requires only a very small change to the existing specification.

    Our suggestion is to allow for monotonic extensibility at any level in the type structure and accommodate this by serializing a length parameter before any nested structure.

    No @Id should be serialized since it is likely that user won't specify IDs when using Extensible types and relying on Ids could break the whole scheme.

    Note that this no longer needs to address DDSXTY12-15 as that issue is already addressed by the resolution DDSXTY12-145

  • Reported: DDS-XTypes 1.1 — Mon, 8 Oct 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Improving Extensible Types

    In DDS-XTYPES 1.1 there are 3 extensibility kinds: Final, Extensible, Mutable. And two encoding formats: PLAIN_CDR and PL_CDR.

    In DDS-XTYPES 1.2 we are adding 2 encoding formats: DELIMITED_CDR and ENHANCED_PL_CDR.

    For simplicity and backwards compatibility DDS-XTYPES 1.2 keeps the same 3 extensibility kinds. But uses the name "APPENDABLE" instead of "EXTENSIBLE". "EXTENSIBLE can still be accepted in the IDL for compatibility. When serializing data the Encoding format is determined by “Extensibility Kind” and the encoding version:

    Extensibility Kind in the IDL Encoding Version Extensibility Kind in the TypeObject Encoding format on the wire
    FINAL 1 FINAL=0 PLAIN_CDR
    FINAL 2 FINAL=0 PLAIN_CDR2
    APPENDABLE 1 APPENDABLE=1 PLAIN_CDR
    APPENDABLE 2 APPENDABLE=1 DELIMITED_CDR
    MUTABLE 1 MUTABLE=2 PL_CDR
    MUTABLE 2 MUTABLE=2 ENHANCED_PL_CDR
  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Type Consistency Enforcement Policy does not allow to properly control type projection/widening

  • Legacy Issue Number: 19405
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The X-Types specification suffers a of inconsistency with respect to how it treats type widening for extensible and mutable types. Specifically widening is always supported for mutable types and never for extensible types.

    That means that given two types X, and Y with Y <: X (read as Y subtype of X) then we have the following cases:

    1. If X and Y are mutable and the TypeConsistencyEnforcementQosPolicy is set to ALLOW_TYPE_COERCION then:
    i. a DR[X] will match a DW[Y] and in this case Y will be
    projected on X.

    ii. a DR[Y] will match a DR[X] and in this case X will be
    widened to Y – by initializing missing attributes
    with default constructors.

    2. If X and Y are extensible and the TypeConsistencyEnforcementQosPolicy is set to ALLOW_TYPE_COERCION then the only possible case is for a DR[X] to match a DW[Y] through a projection of Y on X.

    The inconsistency resulting from the non-uniform treatment of extensible types is not only unjustified but also creates practical issues.

    The fixes that we propose to the specification are the following.

    • Extend the the TypeConsistencyEnforcementQosPolicy to control both type widening as well as projection. Notice that although projection is safe (in most of the case) type widening may not be safe for some applications.

    Thus the the TypeConsistencyEnforcementQosPolicy should be extended to provide the following options:

    1. ALLOW_TYPE_PROJECTION to enable only type
    projection regardless of wether a topic is mutable or
    extensible.

    2. ALLOW_TYPE_WIDENING to enable only type widening

    The conjunction of the previous options should allow for a type to support both projection as well as widening. Otherwise, but this option is less desirable, a third option named ALLOW_TYPE_PROJECTION_AND_WIDENING may be added.

    3. Rename DISALLOW_TYPE_COERCION into
    DISALLOW_TYPE_CONVERSION.

    • Clarify the assignable-from to make it more explicit that type widening is also supported by extensible types.
  • Reported: DDS-XTypes 1.1 — Fri, 2 May 2014 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merged with DDSXTY12-18

    This issue is addressed by the same mechanism proposed to address DDSXTY12-18 and therefore it is being merged with it.

    Even if it had been merged with DDSXTY12-18 it was eventually handled by DDSXTY12-145 which was resolved before DDSXTY12-18

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Enumerations should be represented as a Byte if the bit bound is small enough

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently enumerations can only be represented using Int16 or Int32. But we see no reason why they couldn't be represented with a Byte if the bit bound is 8 or less.

  • Reported: DDS-XTypes 1.1 — Thu, 22 Dec 2016 16:55 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Allow Enumerations to be represented by a Byte if the Bit Bound is 8 or less

    Allow Enumerations to be represented by a Byte if the bit bound is 8 or less. Currently, if the bit bound is 1-16 the representation is Int16.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Add a @non-serialized annotation

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.4.1.3 "Extension to RTPS Standard DCPSParticipants Builtin Topic" of the DDS-Security 1.0 specification defines a @non-serialized annotation. This is used to indicate that a member of an aggregate type should not be serialized.

    This annotation should be moved to XTYPES since it is not specific to DDS-Security and may be needed for other data-types.

  • Reported: DDS-XTypes 1.1 — Tue, 4 Oct 2016 11:43 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Add a @non_serialized annotation

    A @non_serialized annotation is currently defined in the DDS-SECURITY specification. It is not specific to security though, so we are moving it to the XTYPES specification.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

TypeObject IDL and its propagation suffers from significant problems

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The TypeObject IDL in Annex B has some significant problems:

    • The TypeObject of a type embeds its TypeId. However to compute the TypeId one needs to serialize the TypeObject and hash the result. This recursion makes it impossible to create. The work around of first setting the TypeId=0, then computing a "adjusted" TypeObject, serialize and hash it, and use the hash of the "adjusted" TypeObject as its TypeId has been suggested but it is clunky to say the least.
    • Even with the workaround mentioned above the TypeObject format cannot handle recursive types. That is types that refer to themselves which are legal in IDL. For example, there is no way to compute the TypeId of the "child" member f IntTree without having the TypeObject for IntTree which creates an infinite recursion.
    typedef IntTree;
    struct IntTree {
        long  value;
        sequence<IntTree> children;
    };
    
    • There TypeObject IDL uses extensibility(MUTABLE) for many types. This allows multiple equivalent serializations for the TypeObject as members of a mutable type can be serialized in any order. Also there is a choice between serializing them using so called short parameters or "extended" parameters, and also they can be serialized in big endian or little endian. All this means that the TypeId which is a hash computed on the serialized TypeObject can be different depending on how/where it is computed. This is undesirable as the TypeSystem uses the equality of TypeId to detect when types are identical.
    • The TypeObject contains a very detailed representation of the type which is equivalent to the IDL and XML. This is propagated via discovery in the PublicationBuiltinTopic data. This information can be very large (100's of KB) which slows discovery and pushes information to every participant even if they have no interest on that Type, or already know it. Moreover, even when it is used the only need is to check type assignability and that does not require a lot of the information that is propagated with the type
    • The TypeObject is missing the new annotations and types introduced in IDL4.

    In view of this the TypeObject IDL should be refactored in a way that addresses the above problems. Moreover the specification should provide a more efficient way to propagate types that does not involve pushing the TypeObject in the discovery builtin topic data.

  • Reported: DDS-XTypes 1.1 — Wed, 29 Jun 2016 21:11 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Refactor the TypeObject IDL definition and provide a more efficient propagation mechanism

    This resolution includes:

    • A new TypeObject IDL
    • The computation of TypeId for mutually-dependent (recursive) types
    • The propagation of TypeObject (using the request/reply builtin objects)
    • The naming anonymous types.
  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Consider expanding TypeId 16 octets rather than 8

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently the TypeId is 8 octets.
    The TypeId distinguishes identifies a Type and needs to have a low probability of collision relative to the size of the set (collection of types) that can potentially apply to the scope.

    A hash of 64 bits provides reasonably low probability of collision (e.g. < 1 in 10 million) when the set of possible values has a size smaller than 2 million. This was more than enough when we consider the "collection of types" to just be the types that can be associated with a particular Topic on a particular Domain.

    However if we consider the problem of identifying Types across Topics within a Domain, or across domains, or even across applications that evolve over time (e.g. keep a database of TypeId that is built over time) then 64 bits may not be enough...

    We should consider whether to make it 16 bytes now. If these use cases can become important then now would be the time to make the change...

  • Reported: DDS-XTypes 1.1 — Wed, 28 Sep 2016 22:13 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    The size of the TypeID is being increased so hashes are 14 bytes.

    This issue is being merged with DDSXTY12-100 because the resolution of that issue is already increasing the sizes of the hashes in the TypeID to 14 bytes.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

The current assignability rules are complex and too restrictive

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The existing type compatibility rules create situations where DataWriters are not able to communicate with DataReaders because of type differences that could be easily accommodated by the type system.

    The assignability rules for strings are sequences are following the meta-rule: “If type T1 can have an object O1 that is not assignable to type T2, then type T1 is considered un-assignable to T2”. For example according to Table 13 string<256> is unnasignable to string<32> and sequence<long, 256> is unnasignable to sequence<long, 32>.

    Feedback from users indicates that this is undesirable. For example a type may have been designed containing a string<256> but never used to send strings longer than 30 characters. Then in a later version the type is modified to string<32> in order to reduce the max length to the actual size needed to conserve memory resources. This would make the new version of the type incompatible with deployed systems even if all the strings ever sent fit in the string<32> type.

    Type assignability rules are also complex because they are defined as an asymmetric relationship: T1 is-assignable-to T2. rather than a symmetric one. Another complexity comes from the need to define of "strong assignability" which captures the case where T1 is-assignable-to T2 and the end of the T1 object can be determined by T2. This is needed when the T1 appears nested inside another type or in a sequence.

    The main reason to define this asymmetric rule was caused by the previous point of having types like string<10> assignable to string<100> but not the other way around. If we change these assignability rules for strings/sequences then the need for the asymmetric is-assignable-to relationship goes away and can be replaced by a symmetric "is-compatible-with"

    The "strong assignability" is an artifact of the way extensible types are serialized. If they were serialized wrapped with a "length" around them as with the APPEND extensibility we would not need this concept.

  • Reported: DDS-XTypes 1.1 — Sat, 6 Aug 2016 19:47 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Increase flexibility of assignability rules

    Introduce new rules to increase the set of types that are assignable and avoid discarding data as soon as an object that does not "fit" into a target type.

    • Change compatibility of sequences and strings so that the types are compatible regardless of the length. Object initialization requires SOURCE.length <= TARGET_TYPE.length if not the object cannot initialize an object of the TARGET type. This affects Table 13.
    • Introduce a @TryConstruct annotation that can be used to indicate that an unassignable member does not cause the complete object to be dropped. Instead, the member is set to its default value.
    • Allow the use of @DefaultLiteral annotation on enum to allow selecting a default value for an enumeration other than the first or one with smallest member ID.
    • Change compatibility of unions and structures to take into consideration the @TryConstruct annotation.
    • Introduce some clarifying examples

    More details can be found in the attached document: TypeCompatibilityProposal_v3.docx

  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Reserved parameter IDs in 7.4.1.2.1 are wrong

  • Legacy Issue Number: 17295
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Found by: Fernando Crespo, RTI (fernando@rti.com)
    Severity: Significant

    Problem:
    Table 27, "Reserved parameter ID values", in section 7.4.1.2.1, "Interpretation of Parameter ID Values", gives the 14-bit numeric IDs for the reserved parameters. However, it does not specify the corresponding values of the FLAG_IMPL_EXTENSION and FLAG_MUST_UNDERSTAND flags. The implication is that either flag may be set independently on an occurrence-by-occurrence basis, but that would be a bad idea: first of all, if FLAG_IMPL_EXTENSION is set, the specification should assume nothing about the contents of the parameter. And second of all, most parameters have a value of FLAG_MUST_UNDERSTAND that could reasonably be specified up front.

    For example, and in particular, with respect to PID_EXTENDED, the text currently says: "The setting of the FLAG_MUST_UNDERSTAND bit in the 16-bit parameter ID shall be interpreted to apply to the extended parameter as well, not just to the 12 bytes of the PID_EXTENDED parameter itself." In other words, the flag is set based on the the must_understand attribute of a given member. This behavior is inappropriate, given that non-XTypes-conformant DDS implementations may receive extended parameters within discovery data: such implementations, if they do not see FLAG_MUST_UNDERSTAND set, will erroneously interpret the first four bytes of the (extended) data value as a parameter header, effectively corrupting the input data stream.

    Proposed Resolution:
    1. Clearly indicate that any parameter with FLAG_IMPL_EXTENSION set is outside of the scope of the specification. For a parameter to be recognized as one of the well-known values in the table, this bit must be set to zero.

    2. Add a column to table 27 for the FLAG_MUST_UNDERSTAND flag. Set the value of this flag as follows:

    • PID_EXTENDED: Yes. This will force non-XTypes-conformant implementations
      to discard data containing extended headers rather than parsing it
      incorrectly.
    • PID_LIST_END: Yes. This will force implementations to either recognize
      the end of the list or to discard the data. It will avoid a situation
      where an implementation might "skip" the end of the list and start
      parsing out of bounds.
    • PID_IGNORE: No. The whole point is to ignore this parameter.

    3. When writing data, the Service shall conform to the setting of FLAG_MUST_UNDERSTAND indicated above. When reading data, the Service should be robust to the opposite setting as well and accept the parameter nevertheless.

    4. Within the four-bit set of flags that has already been reserved within the extended parameter header, use the most-significant bit to indicate vendor-specific extensions and the second-most-significant-bit to represent the value of the must_understand value of a data member. These flags are parallel to the flags in the short parameter header and restore the flexibility lost by specifying up front the value of the corresponding flags in that header.

    5. Do not leave the contents of the other flags in the extended parameter header with junk contents; if a given flag's value is not specified by some (other) OMG specification, it should be set to zero.

  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Fix and clearly specify the values of flags for parameters reserved in section 7.4.1.2.1

    The values for flags FLAG_IMPL_EXTENSION and FLAG_MUST_UNDERSTAND are either not explicitly stated or are incorrect in section 7.4.1.2.1 "Interpretation of Parameter ID Values". We need to explicitly state the values and fix the values for extended parameters.

    To resolve modify teh specification according to the five steps described as "proposed resolution" in the issue description.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Extended PID is not clear enough what the 2 value lengths mean

  • Legacy Issue Number: 17294
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Found by: Fernando Crespo, RTI (fernando@rti.com)
    Severity: Support Text

    Problem:
    Section 7.4.1.2.1, "Interpretation of Parameter ID Values", says the following directly beneath Table 27, "Reserved parameter ID values":

    "The length of this parameter shall be at least eight bytes: the first
    four bytes of the parameter data shall be interpreted as a set of four
    reserved bit flags followed by the 28-bit member ID; the second four
    bytes shall be interpreted as a 32-bit unsigned data length measured
    from the end of that field until the start of the next 16-bit parameter
    ID. If the 16-bit length is greater than eight, the additional contents
    are undefined and are reserved for future use by OMG specifications."

    The meaning is that the "data value" of the (shorter) parameter is in fact itself a longer parameter ID header, and the length indicated in the former header is in fact the length of that (longer) header only. The actual data value follows both headers, and its length (i.e. until the next parameter header) is given in the longer parameter header. Thus the total length of the parameter following the shorter header is the sum of the two lengths. The values of the flag fields are unspecified, as of the 1.0 specification, and reserved for future OMG specifications.

    Proposed Resolution:
    Update the description to more clearly reflect the data layout and add a figure to show it graphically.

  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarify how to use PID_EXTENDED and add graphic

    The text describing how to use the PID_EXTENDED parameter ID needs clarification and a graphic.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Proposed type-naming scheme is far from Robust

  • Legacy Issue Number: 18292
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The naming scheme proposed in section 7.2.2.3.4 is far from Robust, since the prefixes used to identify a collection may clash with the names of a user defined type. For example: what is a user has created a type called sequence_10, and he creates a sequence of 10 elements from this? The resulting typename would then become sequence_10_sequence_10, for which the parser will assume it is now a 2-dimensional sequence without element type.

    To make robust type names, we should use special characters that are not allowed in the definition of user-defined type names, e.g. sequence<10, sequence_10> or something similar.

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    After applying the resolution of Issue 100 this is no longer a problem

    The problem arises from the fact that TypeObject of every type had to have a name for every types, those names had to be unique and match across implementations .

    However DDSXTY12-100 modified the TypeObject and now anonymous collection types no longer need a name.

    The issue is merged with DDSXTY12-100 so that as part of that resolution the section that talks about naming the anonymous types can be removed as it is no longer needed.

  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Align with IDL4

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In order to simplify the XTypes Specification document and to avoid duplication and/or contradiction, the sections in the XTypes Specification that describe IDL-specific details should be moved to the IDL4 Spec and refer to that spec rather than duplicate the work in both specs.

  • Reported: DDS-XTypes 1.2 — Mon, 19 Sep 2016 20:25 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Align specification with IDL 4.1

    Remove duplicated definitions where we can simply point to the appropriate section in the IDL 4.1 specification.

    This involves for the most part updating annotations that are called differently in the IDL 4.1 specification.

    The revised text contains the annotations @try_construct and @default_literal that were added as part of the DDSXTY12-119 resolution (Sections 7.3.1.3.10 and 7.3.1.3.11 of dds-xtypes-v12_section_7_3_1_3_10_and_7_3_1_3_11_v5.docx, which was attached to the resolution of DDSXTY12-119).

  • Updated: Thu, 22 Jun 2017 16:42 GMT

The encoding of strings and wide strings should be standardized

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Currently, strings and wide strings are treated as mere arrays of chars and wide chars respectively, regardless of their character encoding configuration. This can lead to interoperability issues between systems that assume different encoding configurations implicitly.

    Java and C# languages use UTF-16 encoding, which forces any user who wishes to interoperate their C/C+ application with a Java/.Net application to manually make sure that their strings are encoded in the UTF-16 encoding. There is no API to convert between DDS_Wchar (4 bytes) and a platform’s wchar_t. By default the conversion is done by casting wchar_t to DDS_Wchar, and the fundamental problem is that when casting, after converting back to wchar_t the right character may not be retrieved if the publisher was using a different encoding than the subscriber.

    The proposal is to standardize the wire encoding for char and wide char. For chars we propose using UTF-8 and for wide chars we propose UTF-32 encoding. Along with this change, we should provide conversion APIs to in C/C++ to convert between wchar_t and DDS_Wchar to avoid issues between platforms. For Java and C# the middleware knows the wire encoding (UTF-32) and the native encoding (UTF-16) so the conversion can be done automatically for the user.

    We need to think about how to maintain backwards compatibility with applications that may be using other wire encodings today.

  • Reported: DDS-XTypes 1.1 — Wed, 13 Jul 2016 20:55 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    *Change the standard encoding of strings *

    See the discussion and attached documents in DDSXTY12-113 for rationale behind the decisions to:

    • Not specify an encoding for characters
    • Encode strings using UTF-8
    • Encode wide characters and strings using UTF-16
    • Change the type of WChar to Char16 from Char32.
  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Misleading formulation

  • Status: closed  
  • Source: Siemens ( Pieter Van Vlierberghe)
  • Summary:

    Table 7.4 contains the following misleading statement:
    "It merely provides an alternative name by which to refer to another
    type."
    The point is that alias types are NOT introducing a new type, so "another type" is actually about the same type.

  • Reported: DDS-XTypes 1.1 — Mon, 25 Jul 2016 08:57 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Correct misleading statement

    See issue description on DDSXTY12-118.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Section 7.4.1.2.2 "Member ID-to-Parameter ID Mapping" is underspecified

  • Legacy Issue Number: 17296
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Found by: Fernando Crespo, RTI (fernando@rti.com)
    Severity: Support Text

    Problem:
    The mapping of type member IDs to DDS-RTPS parameter IDs described in section 7.4.1.2.2, "Member ID-to-Parameter ID Mapping", will never result in FLAG_IMPL_EXTENSION being set. However, this is not stated explicitly.

    Proposed Resolution:
    Explicitly state that RTPS parameters corresponding to members of user-defined data types should never set FLAG_IMPL_EXTENSION.

    RTPS parameters corresponding to members of RTPS discovery-defined data types may or may not have FLAG_IMPL_EXTENSION set as defined by RTPS itself; the contract is unchanged. The mechanism by which an implementation generates that flag's value is unspecified.

  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Explicitly State when FLAG_IMPL_EXTENSION cannot be used

    Problem description in DDSXTY12-40. There is no text explicitly stating that FLAG_IMPL_EXTENSION will never be set on user-defined data types. This clarifying text should be added to section 7.4.1.2.2

  • Updated: Thu, 22 Jun 2017 16:42 GMT

ths XSD has many errors

  • Legacy Issue Number: 18781
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Checked with Xerces, the XSD file has many errors which come from the lack of use of namespace.
    Lines: 37, 57, 60, 108, 111, 114, 136, 139, 143, 146, 241, 248, 267, 270, 277, 294, 370, 373, 435, 439, 442, 445, 448, 465, 495, 520, 523, 557, 560, 578, 581, 640
    Xerces error (for the first one: "filename"): "E [Xerces] src-resolve.4.1: Error resolving component 'fileName'. It was detected that 'fileName' has no namespace, but components with no target namespace are not referenceable from schema document 'http://www.omg.org/spec/DDS-XTypes/20120202/dds-xtypes_type_definition.xsd'. If 'fileName' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'fileName' has no namespace, then an 'import' without a "namespace" attribute should be added to 'http://www.omg.org/spec/DDS-XTypes/20120202/dds-xtypes_type_definition.xsd'."
    W3C reference:
    http://www.w3.org/TR/xmlschema11-1/#src-resolve

  • Reported: DDS-XTypes 1.1 — Mon, 17 Jun 2013 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Fixing Namespace in XSD files

    The original XSD schemas had multiple problems related to namespaces.

    To address these issues and make it simpler for other specifications to refer to the types define in the schema included in the specification, we are applying the so-called Chameleon Namespace Design, dividing the original schema into two different XSD files:

    1. dds_types.xsd, which can be used by applications to validate the types defined in an XML file. This file sets targetNamespace="http://www.omg.org/dds/".
    2. dds_types_definition.xsd, which includes all the type definitions without specifying a targetNamespace.

    Accompanying these two XSD files we include a non-normative XML file that demonstrate how to load dds_types.xsd with the right namespace to define a set of data types.

  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Mapping of Map type underspecified for C

  • Legacy Issue Number: 18304
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Section 7.5.1.3.1 is referring to a C-mapping defined above. However, no C-mapping is mentioned so far, or it should refer to section 7.5.1.3.3
    Section 7.5.1.3.3 seems to suggest the C-mapping should be done as in section 7.4.1.1.4, which is a sequence of name-value pair structs. I can't imagine that this is a serious mapping proposal, but if it is is should be clearly specified as such

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clearly define a C mapping for Map types

    The C mapping for map types is not well-defined and needs to be added.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

C++ shared member representation breaks safety mechanisms of the struct containing it

  • Legacy Issue Number: 18303
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    By clearly stating that a shared member must map onto a plain pointer, not a _var type or other smart pointer you are breaking the safety mechanisms that the C++ struct had inherently built into it, since on destruction or re-assignment the shared pointer may now leak away. The whole point of using _var types or other smart types was to prevent this from happening. I see no good reason why to make this one exception for shared pointers, which will make it much harder to predict the struct's behaviour.

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Define the language binding for shared members in C and C++

    Shared members are currently mapped to plain pointers in C and C++. This mapping prevents safety mechanisms, such as shared pointers in C++, from being used to automatically handle the memory management of these members. We are redefining the language mapping to add in these safety mechanisms and to allow the memory to be handled differently on the sending and receiving sides of an application.

  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:
    • External.hpp.docx 9 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Contradictions in the assignability for collection types

  • Key: DDSXTY12-9
  • Legacy Issue Number: 19269
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The OMG approved more-restrictive assignability rules (OMG Issue No 16368). However, some examples in the current spec (Version 1.0, February 2012, OMG Document number ptc/2012-03-26) remain unchanged and contradict those new rules.
    For example, on page 39, we say that a sequence of 10 integers is assignable from a sequence of 20 integers, although some objects may not be. This is no longer true according to the new rules--the destination sequence bound must be greater or equal than that of the source sequence (see Table 13 on page 40).

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merged with DDSXTY12-119

    This issue has been subsumed by DDSXTY12-119. Therefore it should be merged into it.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Mapping of optional arrays in C/C++

  • Legacy Issue Number: 19272
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Spec does not specify the C/C++ mapping of optional arrays.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Add an example of how to declare an optional array for C and C++

    Optional members already map to pointers in C and C++, but the syntax of declaring a pointer to an array of objects rather than an array of pointers to that type of object is tricky. We would therefore like to provide an example of how to do this.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Unify name used for Aggregate and Enumerated types


Built-in annotations should be in DDS namespace

  • Legacy Issue Number: 17293
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Found by: Rick Warren, RTI (rick.warren@rti.com)
    Severity: Minor

    Problem:
    The IDL Type Representation uses so-called "built-in annotations" to attach metadata to type definitions. The hypothetical module in which these annotations are defined is unclear. On the one hand, all (other) types defined by the specification are in the DDS:: module. However, in the case of the built-in annotations, no module is specified.

    Proposed Resolution:
    Clearly indicate that all built-in annotations are notionally in the DDS:: module

  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merge with DDSXTY12-34

    This can be treated together with DDSXTY12-34 which is already aligning annotations with the syntax of IDL4

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Rendering of UML diagrams in each of the figures is of poor graphical quality

  • Legacy Issue Number: 17018
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The gradient shading rendered in each of the elements on a low-color image results in elements rendered as follows:

    The diagrams should be rendered either by using a higher-color format (such as png), or without the gradient rendering enabled.

    NB: To turn off the gradient shading in Enterprise Architect, go to the "Tools->Options" dialog. Under the "Diagram->Appearance" group:
    1) Deselect the "Show Gradient Fill for Paper Color" option
    2) Set the "Gradient Fill Direction for an Element" to "<none>"

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    This issue was already fixed on previous revisions

    The issue was in the adopted submission but it was resolved in version 1.0 and subsequent versions.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

All IDL should use local interfaces

  • Legacy Issue Number: 15946
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    All IDL should be using local interfaces, not regular interfaces, please add the keyword local to all interfaces

  • Reported: DDS-XTypes 1.0b2 — Thu, 13 Jan 2011 05:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    No change needed as local interfaces are being deprecated in IDL4

    The use of IDL in XTYPES needs to be re-examined in light of IDL4. Specially features that are not part of the "DDS Profiles" defined in IDL4.

    XTYPES uses local interfaces to define the DynamicData and DynamicType interfaces. It also uses them to define annotations. XTYPES uses regular interfaces to define the TypeSupport interface. IDL4 local interfaces belong to the CORBA-Specific building block. They are not part of the "DDS Profiles"
    XTYPES uses (non-local) interfaces to define TypeSupport. This is in the RPC over DDS profile of IDL4.

    XTYPES uses valuetypes to describe parts of the DynamicData and DynamicType interfaces. These are part of the Building Block ValueTypes which is not in any of the the "DDS Profiles"
    Note that the fact that XTYPE uses a specific IDL building block (BB) does not mean that implementations of XTYPES that would end up having to support that BB. As long as that dependency on the BB is limited to describing interfaces that are "built into" the XTYPES DDS APIs there is no problem. If however they form part of the code being generated from user-defined datatypes then we would really have an issue.
    The issue with "local" interfaces is that IDL4 considers them deprecated and for that reason it included them in the CORBA module.

    The IDL4 view is that interfaces are just a contract specification, whether they are local or not is more up for interpretation by a particular use of the IDL. Hence this is specified via annotations like @service(DDS) or @service(CORBA). Therefore if an interface does not state anything it can be interpreted as a "local" interface...

    So while the current use of local interfaces and valuetypes on XTYPES appears fine, it may make sense (in light of IDL4) to actually remove all use of "local" interfaces replacing them with regular interfaces...

    However at this point it seems best to leave things as they are and wait for the alignment with IDL4...

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Extended parameters should be aligned the same as non-extended ones

  • Legacy Issue Number: 17297
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Found by: Fernando Crespo, RTI (fernando@rti.com)
    Severity: Support Text

    Problem:
    The section on the parameterized CDR Data Representation (DDS-XTypes 7.4.1.2) contains a reference to the DDS-RTPS specification for the definition of the parameter list data structure. However, it does not specifically refer to the instructions in DDS-RTPS on how to handle alignment within such a structure. This omission may confuse some implementers, especially with respect to extended parameters, which should follow the same alignment rules as RTPS-traditional "short" parameters.

    Proposed Resolution:
    Add the following paragraph to the end of section 7.4.1.2.1, "Interpretation of Parameter ID Values":

    "The alignment rules for extended parameters shall be the same as
    those for non-extended parameters, which are defined in [RTPS]
    Section 9.4.2.11."

  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Specify alignment of Extended Parameters

    Accept the suggestion from the issue description.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

IDL annotation syntax fails to specify scoping rules for annotation type names

  • Legacy Issue Number: 19145
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    There is no clear specification of whether annotation types are part of the same naming scope as other IDL declared types or not.
    The Type System Model described in chapter 7.2.2 seems to indicate they are all declared in a single naming scope as an annotation member could have "any enumeration type". In IDL this would require them to have the same naming scope as IDL declared enum types.
    As a consequence it would mean that annotation type names could clash with type names used by 'regular' local interface definitions.
    It would also seem to indicate that annotation application syntax would have to support scoped naming like "@Test::MyAnnotation()".
    Clear specifications for all these considerations are missing from the spec.

  • Reported: DDS-XTypes 1.1 — Sun, 15 Dec 2013 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Combine with DDSXTY12-34

    This problem is partly caused by the use of "interfaces" to define annotations.
    However annotation names should never conflict with any other types (interfaces or otherwise) as their use is proceeded by the character "@".
    IDL4 new syntax for declaring annotations makes it more obvious by using the keyword "@annotation" to define annotations.
    Since legacy IDL compilers are no expected to parse the annotation declarations it seems that this issue will only affect the new compilers.

    IDL4 does declare scopes for applying annotations, but all the builtin annotations (which include the XTYPES ones) are defined in the global scope.

    Therefore this issue should be solved the same way as XTYPE12-34 ideally aligning the syntax with that of IDL4.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Deserialization issues with Extensible types

  • Legacy Issue Number: 19270
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Spec: DDS-XTYPES
    Document Number: ptc/2013-12-18
    Revision Data: 2013-12-18
    Version 1.2
    Nature: Enhancement
    Severity: Significant
    Title: Deserialization issues with Extensible types

    Problem description

    The XTypes specification uses "traditional" CDR to represent extensible types on the wire.

    The usage of "traditional" CDR encapsulation poses a problem in some scenarios where a DataReader with an extensible type "A" receives samples coming from a DataWriter with an extensible type "B" and where type "B" contains a subset of the members in type "A" (base to derive relationship). For example:

    struct TypeB  {
       char member1;
    };
    struct TypeA {
      char member1;
      short member2;
    };
    

    At first sight, the usage of traditional CDR is enough to deal with the scenario described above:

    The deserialize operation for type "A" will deserialize member1. After that, the function will try to deserialize member2 but it will find that there are no more bytes in the input stream. In the absence of a value for member2, the deserialize function will initialize this member with its default value 0.

    So far so good.

    The problem is that the previous algorithm works fine only when the number of bytes in the input stream (serialized sample published by the DataWriter) is exactly equal to the number of bytes produced by the serialization function for Type "B". In our example, this number is 1. Unfortunately, in some scenarios, including our example, the number of bytes in the input stream will include some padding bytes that are added to guarantee that the RTPS DATA sub-message containing the sample published by the DataWriter has a size divisible by 4.

    The PSM in the RTPS specification requires that each sub-message is aligned in a 32-bit boundary with respect to the start of the RTPS message.

    In our example, the deserialization function for Type "A" will receive a stream with 4-bytes (1 for the char in member1 and 3 bytes for padding). Because of that, the previous algorithm may end up initializing member2 with padding bytes. Since padding bytes may have a value different than 0 the member2 value will not necessarily be equal to zero.

    Affected types

    The previous issue may occur when all the following conditions are met:

    • The top-level types used by DataReader and DataWriter are extensible.
    • The DataReader type is assignable from the DataWriter type and it contains more fields at the end (see example above).
    • The last primitive member on the DataWriter type is: char, octet, boolean, short, unsigned short, or string. Other types are not a problem because they require 4-byte alignment and the middleware will not have to add padding bytes at the end of the DATA message.
    • The first primitive member on the DataReader type after the last primitive member on the DataWriter type is: char, octet, boolean, short, unsigned short. Other types are not a problem because they require 4-byte alignment. The deserialization function will not use the padding bytes at the end of the DataWriter's sample to initialize the contents of the first primitive member on the DataReader type.

    For example:

    struct TypeB {
      char member1;
    };
    struct TypeA {
      char member1;
      short member2;
    };
    

    The previous two types will be problematic.

    struct TypeB {
      long member1;
    };
    struct TypeA {
      long member1;
      short member2;
    };
    

    The previous two types will be OK.

    struct TypeB {
     string member1;
    };
    struct TypeA {
      string member1;
      short member2;
    };
    

    The previous two types may be problematic or not depending on the value of member1.

    struct TypeC {
     char member1;
    };
    struct TypeB {
      TypeC member1;
    };
    struct TypeA {
      TypeC member1;
      short member2;
    };
    

    The previous two types will be problematic since the first primitive member of TypeB (including nested types) is a char.

    Are Mutable Types Affected?

    This problem does not affect mutable types directly. However, it may affect mutable types when they contain members of extensible types.
    For example:

    struct TypeB {
      char member1;
    };
    struct TypeBMutable {
      TypeB member1;
    }; //@Extensibility MUTABLE_EXTENSIBILITY
    struct TypeA {
      char member1;
      short member2;
    };
    struct TypeAMutable {
      TypeA member1;
    }; //@Extensibility MUTABLE_EXTENSIBILITY
    

    Mutable members are encapsulated using parametrized CDR representation.

    Each member, within a mutable type is simply a CDR-encapsulated block of data. Preceding each one is a parameter header consisting of a two-byte parameter ID followed by a two-byte parameter length. One parameter follows another until a list-terminating sentinel is reached. Parameter headers must be aligned to a 4-byte boundary. If the serialized length of a member value is not divisible by 4, the implementation will add some padding bytes.

    The problem is that the length field of a mutable member represents the data length measured from the end of that field until the start of the next parameter ID (this is part of the XTypes specification). Therefore, the deserialize function for the member type may receive as input a stream containing the padding bytes.

    IN Implementation Changes

    To reduce the number of scenarios in which we run into the problem we will initialize the padding bytes to zero. This includes the padding bytes at the end of the serialized sample, and the padding bytes at the end of a mutable member serialization.

    By doing this the following scenario would not be an issue anymore

    struct TypeB {
      char member1;
    };
    struct TypeA {
      char member1;
      short member2;
    };
    

    In the previous example the deserialize function would use padding bytes to initialize member2. However, since these padding bytes have a zero value, the value assigned to member2 would be the right value.

    With the previous fix we would have issues only when the first primitive member on the DataReader type is char, octet, boolean, short, unsigned short and in addition it is the discriminator of a union.

    For example:

    struct TypeB {
      char member1;
    };
    union UnionA switch (short) {
      case 0:
         long member1;
      default:
         long member2;
    };
    struct TypeA {
      char member1;
      UnionA member2;
    };
    

    To detect the previous problem, we will change the type compatibility algorithm so that it reports an error when the issue occurs.

    Potential Changes to the XTypes Specification

    Resolving the extensibility problem described above for all the scenarios will likely require changes to the XTypes specification.

    For the top-level types, we propose to use two bits from the options bytes following the encapsulation identifier to identify the padding.
    For example:

    struct TypeB {
      char member1;
    };
    

    In the previous example a sample for Type B would be encapsulated as follows:

    CDR_BE x x x x x x x x x x x x x x 1 1
    member1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

    Notice that the value '11' in the options indicates the number of padding bytes.

    For mutable members we propose to change the interpretation of the length field to not include the padding bytes to the next header.
    For example:

    struct TypeB {
      char member1;
    };
    struct TypeBMutable {
      TypeB member1; //@ID 1
    }; //@Extensibility MUTABLE_EXTENSIBILITY
    

    In the previous example TypeBMutable would be encapsulated as follows:

    CDR_BE x x x x x x x x x x x x x x 0 0
    ID 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
    member1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    PID_LIST_END 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

    Notice that the length field for the member with ID 1 is set to 1 instead of 4

    Forward compatibility

    The changes described in the previous section should not affect backward compatibility with previous XTYPES compatible versions.

    Let's assume two XTYPE versions:

    • One DDS compliant with XTPES 1.1 and already deployed
    • A future DDS compliant with XTPES 1.2 incorporating the changes to the XTypes spec described in the previous section

    TOP-LEVEL Types:

    • XTYPES 1.1 DataReaders should ignore the option bits set by the XTYPES 1.2 DataWriters
    • XTYPES 1.2 DataWriters receiving samples from XTYPES 1.1 DataReaders will assume that there are no padding bytes

    MUTABLE Members

    • XTYPES 1.1 DataReaders will receive members with a header where the data length is smaller than expected. This should not be a problem because the DataReader will always align the beginning of the next parameter to a 4-byte boundary. Therefore, the padding bytes will be skipped by the align operation.
    • XTYPES 1.2 DataReaders will receive members with a header where data length includes padding. That should be fine as well. The align operation to go to the beginning of the next parameter will be a NOOP.
  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Fix the deserialization issues related to padding

    Modify the XTYPES specification to use the option bits that follow the encapsulation options to encode the number of padding bytes. Follow what is stated in the issue description. In addition padding bytes should be set to zero.

    Clarify/state that the lengths for both short and long member IDs encode the exact length of the serialized member without accounting for padding bytes.

  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

Issues with UNIONS assignability rules

  • Key: DDSXTY12-5
  • Legacy Issue Number: 19265
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The IDL specification (pre-XTypes) allows the declaration and usage of unions that do not cover all possible discriminator values. For example:

    union Z switch(boolean)
    { 
      case TRUE: 
        short s; 
    };
    

    In the previous union, it is possible to set the discriminator to FALSE. When that occurs, the union's value is composed solely of the discriminator value FALSE.
    The new XTypes specification has several issues concerning unions like the one before:
    It is not clear that you can set the discriminator to a value that is not associated with an union member. For example, can you set the discriminator to FALSE in the union Z?.
    The assignability rules may break assignability of a union object to itself. For example, with the previous UNION, if a received sample has a discriminator value of FALSE, it will be dropped according to the following rule in the Behavior column in table 15:
    If the discriminator value does not select a member in T1 then the T2 object is unassignable to T1.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Duplicates DDSXTY12-119

    This issue is being merged into the a broader issue (DDSXTY12-119) that seeks to make the assignability rules simpler and less restrictive. The resolution of DDSXTY12-119 issue includes changes to the Union assignability rules which addressed the concerns DDSXTY12-5 raises.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Applicable key types not clearly specified

  • Legacy Issue Number: 18293
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In section 7.2.2.3.5.6 it is stated that every member of a struct can act as key. If that is indeed the case, then keys could be set on attributes of type sequence or union for which the resulting behaviour is not clearly specified. (For example, how to compare a key from a sequence of length 1 to a key of a sequence of length 2? How to compare unions that have the same discriminator but different branch values? How to compare unions that have different discriminator values that map onto the same branch?)

    Either setting keys on sequence and union attributes should be prohibited, or the resulting behaviour should clearly be specified.

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Specify members of type Union, Array and Sequence can be keys

    Unions types can either be keyed or not. If keyed, the only union attribute that can form part of the key is the discriminator as it is the only attribute guaranteed to always be there.

    To indicate a union has a key the discriminator is annotated with the @key. See 7.3.1.2.2 (the switch in the union can have annotations).

    If the Union had not declared a key (its discriminator as key). Then it is unkeyed. And when used as a member and marked as key the whole value (discriminator included) would form the key.

    Allow BitSet, Arrays and Sequence member to be used as keys. Those are simple. But not maps. These could be added later if the need arises.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

DataRepresentationQosPolicy is making the application responsible for transport

  • Legacy Issue Number: 18306
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Using a QosPolicy like DataRepresentationQosPolicy is breaking the abstraction between application and transport. This is fine if the application is managing its own transport, but not if the transport is implemented by some external service. We see no reason why this policy should be implemented as part of the XTypes specification as cleary it has no relationship to type extensibility.

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    Issue was withdrawn by the originating company

    Upon discussion during RTF the issue was withdrawn by the originating company.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

A @Version annotation shall be added

  • Legacy Issue Number: 18145
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The X-Types specification does not provide any way of attaching version information to topic types. This is unfortunate as this information is quite essential to help debug running systems by identifying which version of the information model each element is working with.

    As a consequence a new annotation @Version should be added for topic types. A possible definition of this annotation is shown below:

    @Annotation
    local interface Version

    { attribute unsigned long major; attribute unsigned long minor; attribute unsigned long patch_level; }

    ;

  • Reported: DDS-XTypes 1.1 — Mon, 8 Oct 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Add a @Version annotation

    The RTF discussed what the purpose of the @version annotation was and it was determined the value comes from situations were there is a single authority/governance body that controls the type system.

    In this situation, having some "version" annotation that can distinguish intentional changes/evolutions of a type versus some error can be a useful "system integration" aid. The idea is that each time someone modifies a type in a system it would tag it with some "application meaningful" (it could be a version number like major.minor.revision, or a date, or some other label). Then duding deployment when compatibility of types between DataWriter and DataReaders is examined this additional tag is available.

    Type compatibility is determined using the "assignability rules" this done independent of the version number/tag. In addition to this:

    • If the tags are different (or absent in one side) then there no additional things to do.
    • If the tags are the same but the types are not identical, then this could trigger some warning/errors coming via DDS status/listeners. The fact that the same version tag was used indicated the application was trying to use the same version of the types for that writer/reader. The fact that they did not match indicates that there was some process error and somehow the two applications ended up with different types.

    There was agreement in the RTF that this was a useful feature, but leaving the version as an "unstructured" string. Without adding version numbers, dates, etc. It just needs to be checked for equality and it is up to the people defining the type system to create their own convention.

    The RTF discussed whether it made change to have a different behavior at the DDS level. The most "obvious" one suggested was to force "mismatched type" error for types that were assignable/compatible but not identical if their version tag was the same. Idea is similar to the compiler option of "error on warnings". Make it harder for people to deploy systems with this type of inconsistency. At the same time it was agreed that most of the benefit of this feature could be obtained using a tool that would monitor the types and detect that inconsistency. And this would not require a forceful change in matching behavior.

    The RTF agreed to add the @version annotation and describe the intended use, but not force any implementation behaviors. It would be up to vendors to provide tools around this or support a "error" behavior on those types with identical version and non-identical structure... If in the future the vendors determine that the "fail" behavior is important to support and must be made interoperable then it can easily be added without breaking deployed system

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Key order should be defined using the @Key annotation

  • Legacy Issue Number: 18144
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The X-Types specification had left under-defined mechanism to be used for specifying the order of key attributes.

    The solution adopted by the FTF was to simply use the member ID to define such an order, but this is not optimal.

    We strongly suggest to define @Key annotation as follows:

    @Annotation
    local interface Key

    { attribute unsigned long value; attribute boolean value default true; }

    ;

    Where the value attribute is used to define a total order among the key attributes.

  • Reported: DDS-XTypes 1.1 — Mon, 8 Oct 2012 04:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    No change as it could be done as a vendor extension without affecting portability/interoperability

    Ordering of the keys for the purpose of sorting is something that can be handled internally by each vendor since there are no APIs in DDS that specify an order relative to the key order (e.g. the read_next_instance() specifies an order "by instance handle" which is not explicitly mapped to keys).
    In other words, a vendor could add an annotation e.g. @key_order to define the order and use that to optimize how samples are stored in the cache but it would not affect portability or interoperability.

    Making it part of the key definition itself would render types as incompatible as a result of something that seems more like a local optimization of a cache in a specific application which would not affect applications in other nodes.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Allow empty structures

  • Legacy Issue Number: 19274
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Allow empty structures as part of the XTypes spec. XTYPES spec it does not require structures to have any members. It is not explicit about this but it does say they
    can have any number of members (including zero). The IDL syntax. XTYPES uses IDL as one of the ways to express types so if the IDL grammar specifies made empty structures
    illegal we would have an inconsistency between what the X-TYPES type-system says and what the IDL grammar supports...
    Looking at the IDL syntax in the X-Types it defines:
    <struct_type> ::= <struct_header> “

    {” <member_list> “}

    The <member_list> refers to the production on the IDL spec (X-TYPES
    only lists the new productions or the ones that are modified from
    IDL), the <struct_type> is modified in XTYPES to support inheritance,
    hence its appearance in the XTYPES duc but the <member_list> is
    unchanged.

    In IDL 3.5 <member_list> is defined as:

    <member_list>::=<member>+

    Which does seem to indicate that empty structures are not supported.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Closed; Out Of Scope — DDS-XTypes 1.2
  • Disposition Summary:

    The change should be applied to IDL 3.5/IDL4

    Supporting empty structures is desired to facilitate the mapping from other data-models that may support them in that sense the type system in XTYPES is already doing the right thing and it is IDL the one that needs to change...

    Given that the plan is to remove the IDL syntax extensions from XTYPES and have XTTPES reference IDL4+ instead. It is best to close this issue here with "NoChange" and instead file an issue with IDL4 to add support for empty structures.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

member ID algorithm flawed

  • Legacy Issue Number: 18298
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In section 7.3.1.3.1 is is stated that when explicitly assigning memberID's to some attributes (but not to all attributes), that:

    "In such cases, implicit values are assigned in a progression starting from the most-recently specified ID (or an implicit value of zero for the first constant, if there is no previous specified value) and adding one with each successive member."

    This algorithm could result in the same memberId being assigned multiple times. Consider the following example:

    struct A

    { long x; //@id 2 long y; //@id 1 long z; }

    ;

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Add clarifying text to section 7.3.1.3.1

    The main part of this issue is addressed in DDSXTY12-18. Therefore, the only thing we need to do here is clarify the member ID rules.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

IDL annotation syntax does specify how to use Any member type

  • Legacy Issue Number: 19144
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    According to the Type System model in chapter 7.2.2. the Any type is allowed as an annotation member type.
    The IDL syntax does however not specifiy if and how that type could ever be used in IDL.
    Since standard IDL has now way to declare an Any value it seems logical that the IDL syntax should specify the Any type off limits for annotation types declared in IDL.

  • Reported: DDS-XTypes 1.1 — Sun, 15 Dec 2013 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarify the IDL type "Any" is not part of the DDS-XTYPES type system

    This issues seems is the result of a confusion in the interpretation of the word "Any" when it is used in Section 7.2.2.3.6 (Annotation Types). That section says that the members of annotation types are restricted to certain types.
    These are:

    • Any Primitive type
    • Any String type of Char8 or Char32 elements
    • Any enumerated type

    In the above the word "Any" is used as an adjective and not to mean the type represented by the IDL "Any" keyword.

    To avoid this ambiguity the issue resolution will reword the bullet points removing the word "Any".

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Annotation member default declaration not compatible with Legacy IDL

  • Legacy Issue Number: 19143
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The DDS XTypes IDL Type representation spec defines an "alternative" annotation declaration for use with legacy IDL. This alternative syntax is however not compatible with legacy IDL compilers because it does not take into account that legacy attribute declarations do not support the 'default' value declaration used in the annotation syntax.
    To be compatible it should be specified that for the legacy syntax the attribute default declaration is not allowed.

  • Reported: DDS-XTypes 1.1 — Sun, 15 Dec 2013 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merge with DDSXTY12-122

    DDSXTY12-34 is to be addressed as part of the broader issue of aligning the XTypes specification with the IDL4 Specification (DDSXTY12-122).

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Builtin topics not backward compatible

  • Legacy Issue Number: 18310
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Builtin topics are not backward compatible with the DDS1.2 spec (not even according to the rules of the Extensible types spec itself).

    As an example, the BuiltinTopicKey_t array has been extended from 3 elements to 4 elements. This breaks compatibility with respect to non-xTypes compliant versions of a DDS product, and it is not cleared up why the keyfield suddenly required this extra element.

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Modify definition of BuiltinTopicKey_t to align it with RTPS spec

    In appendix D modify the BuiltinTopicKey_t to be wire-representation compatible with the RTPS spec.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Expose assignability options for ignoring member names and sequence lengths

  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The XTypes spec is too restrictive because it does not allow ignoring member names and sequence length in type compatibility. The spec should provide such flexibility. TypeEnforcementQoSPolicy should be extended to allow more flexibility.

  • Reported: DDS-XTypes 1.1 — Fri, 9 Oct 2015 20:59 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Include support for ignoring member names

    Ignoring member names in type consistency enforcement is a desirable QoS policy. Extended the TypeConsistencyEnforcementPolicy with a boolean condition. Updated section 7.6.2.3.2 and Annex D.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Keyhash computation not well-defined for mutable types

  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Keyhash computation is not specified precisely enough. For instance, for mutable types it is not clear whether to use short/long parameter IDs and for PID_SENTINEL whether to set must-understand bit = 1/0? As a result, the keyhash for the same key may be different from different vendors.

  • Reported: DDS-XTypes 1.1 — Fri, 9 Oct 2015 20:53 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Update keyhash computation for mutable types

    Removed ambiguities from keyhash computation algorithm for mutable types. Specifically the following ambiguities existed.

    1. Whether to use short/long parameter encapsulation
    2. What's the value of must-understand bit in PID_SENTINEL.

    Both ambiguities are avoided using the revised algorithm.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

specify language-specific bindings may exist

  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Include a sentence in section 7.5 Language Binding that language-specific PSMs might overrule some or all of the language binding rules specified below.

  • Reported: DDS-XTypes 1.1 — Thu, 10 Sep 2015 21:56 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Added clarification

    Added clarification in section 7.5 first paragraph.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

One sentence split in two bullets

  • Legacy Issue Number: 19587
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    As part of section 7.2.2.3.7.1 the last two bullets should be one, so change

    • The string “*” (an asterisk) shall indicate that
    • text applies to all programming languages.

    to

    • The string “*” (an asterisk) shall indicate that text applies to all programming languages.

  • Reported: DDS-XTypes 1.1 — Tue, 26 Aug 2014 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    *Incorporated editorial changes *

    Editorial change in Section 7.2.2.3.7.1 bullet #4

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Spec should allow any value for the Optional flag in TypeObject union members

  • Key: DDSXTY12-6
  • Legacy Issue Number: 19266
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    By definition, union members are always optional. The spec should allow implementations to decide whether union members include the optional flag as part of the TypeObject member flags. In any case, implementations should ignore that flag for equality and type-compatibility purposes.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Duplicates DDSXTY12-11

    Duplicates DDSXTY12-11

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Optional flag in TypeObject union members

  • Legacy Issue Number: 19273
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    By definition, union members are always optional. The spec should allow implementations to decide whether union members include the optional flag as part of the TypeObject member flags. In any case, implementations should ignore that flag for equality and type-compatibility purposes

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Duplicates DDSXTY12-11

    Duplicates DDSXTY12-11

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Optional flag in TypeObject union members

  • Legacy Issue Number: 19271
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    By definition, union members are always optional. The spec should allow implementations to decide whether union members include the optional flag as part of the TypeObject member flags. In any case, implementations should ignore that flag for equality and type-compatibility purposes.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Indicate the TypeObject union sets the member's isOptional flag to false.

    Union members shall have the IS_OPTIONAL set to 0 since the semantic is that if a member is selected then it has to be present.

    In the future we may want to support the @optional annotation on the union member to indicate that the selected member could be omitted. This is currently not supported in the IDL syntax. However if this were to change in the future, the future version of XTYPES could support it by setting the IS_OPTIONAL flag to 1 for those members.

    Furthermore indicate only the discriminator member can be declared as a key member for the union.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

The description for union types are not complete

  • Key: DDSXTY12-4
  • Legacy Issue Number: 19264
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    For Union Types the xTypes spec does not handle the following two cases:
    What is the criteria to select a value for the discriminator when a default case is specified?
    What happens if a default case label is specified when the set of case labels completely covers all the possible values for the discriminator.
    Note: This information is stated in section 1.9 (Mapping for Union) of the IDL to Java spec.
    If the branch corresponds to the default case label, then the simple modifier for that
    branch sets the discriminant to the first available default value starting from a 0 index
    of the discriminant type.
    It is illegal to specify a union with a default case label if the set of case labels
    completely covers the possible values for the discriminant*. It is the responsibility of
    the Java code generator (e.g., the IDL complier, or other tool) to detect this situation
    and refuse to generate illegal code.
    Proposal to determine what is the default value for a union discriminator:
    If there is no default case value, the default discriminator value is the lowest value associated with any union member. If the discriminator type is an enumeration, the value is the enumerator with the lowest ordinal.
    if there is default case value:
    For integer, boolean, byte, char, wchar: The default discriminator value is the first available value starting from a 0 value of the discriminant type.
    For enumerations: The default discriminator value is the first enumerator in the order declared in the enumeration that is not associated with any case value.

  • Reported: DDS-XTypes 1.1 — Thu, 27 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Duplicates DDSXTY-12-5

    Duplicates DDSXTY-12-5

  • Updated: Thu, 22 Jun 2017 16:42 GMT

lookup_topicdescription semantics make it unusable

  • Legacy Issue Number: 18309
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Section 7.6.3.2 specifies that lookup_topicdescription returns 1 matching representation. On multiple matches, an arbitrary representation is returned.

    This is not helpful in any way for an application trying to access a certain representation. Either its signature should be changed to return a sequence of topic representations, or it should cyclically go over each representation and return 1 at a time, so that subsequent invocations may return different representations.

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarified semantics of lookup_topicdescription

    Added clarifications in section 7.6.3.2. and enhanced PIM-to-PSM mapping for this operation as described in the revised text.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Multiplicity mismatch between TypeName and TypeObject

  • Legacy Issue Number: 18307
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The builtin topics have 2 ways to identify the type to which they apply: a string called type_name and a TypeObject alled type. The string can only relate to 1 type, while the TypeObject could refer to more than 1 type.

    If the type_name is not uniquely identifying a type, then what is the use of having a type_name in the builtin topics for Reader and Writer? The topic_name already refers to a DCPSTopic sample that has a similar type_name.

    Furthermore, in the spec it is assumed that Readers/Writers just make the TypeObject refer to just 1 type, while the Topic could make it refer to more than one. This is not orthogonal, so wouldn't it be better to make a TypeObject refer to 1 type and give the DCPSTopic a sequence of TypeObjects instead?

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    ChangeType object to refer to a single TypeId

    Modify Annex B to correct the multiplicity of the TypeId. The TypeObject struct (Annex B) shall be updated to include just a single typeid instead of a sequence of typeids.

    The TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData already includes an optional TypeObject member. The specification shall include a guideline/warning that absent TypeObject it is not possible to ensure type compatibility

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Shareable members underspecified

  • Legacy Issue Number: 18295
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    There are some questions regarding shared members that should clearly be addressed in this section:

    • Are shareable members always implemented as pointers in the way optional members are?
    • If so, can a shareable member be NULL?
    • If so, then is a shareable member not by definition also an optional member?
    • What will happen when I pass object graphs, even when the last sentence warns against this? (e.g. marshaling into 1 big blob anyway, passing an error, etc.)
    • May a shareable member be, or contain a key?
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Added clarification for Shareable members

    Updated the description in section 7.3.1.3.4.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Circular dependencies across types should be allowed

  • Key: DDSXTY12-8
  • Legacy Issue Number: 19268
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The XTypes spec does not make clear whether or not circular dependencies across types are allowed. They should be allowed.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Added clarification for Shareable members

    The necessary clarifications for this issue are added in section 7.3.1.3.4 Shareable Data through a different issue DDSXTY12-21.

    Essentially, circular dependencies are allowed but the m/w is not required to detect or warn against such uses.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

TypeId calculation errors/corrections

  • Key: DDSXTY12-7
  • Legacy Issue Number: 19267
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Section 7.3.4.1.2 Type Hierarchy in the XTypes spec explains how to calculate the TypeId for a given type.
    The description provided contains errors and ambiguities that must be resolved.
    1.- The spec explains that the TypeId of a constructed type is calculated by serializing the type in big-endian CDR data representation. However, the TypeId itself is part of the Type (ArrayType, StructureType). We cannot serialize without the TypeId and we cannot get the TypeId without serializing.
    To resolve this problem I am setting the Type's TypeId to the following value before serializing:
    RTI_CDR_TYPE_OBJECT_NO_TYPE (for the discriminator)
    RTI_CDR_TYPE_OBJECT_NO_TYPE_ID (for the union value)
    2.- The Type (ArrayType, StructureType) also has a member containing the type name (not fully qualified). The value of this member is used to calculate the TypeId. Since the name is not fully qualified, two identical types within different modules will have the same TypeId. The question is whether or not the type name should be used as part of the TypeId calculation.
    If the type name must be used as part of the calculation and it discriminates, then we will have to use the fully qualified name. Otherwise two identical types within different modules would get same TypeId.
    If the type name should not be used as part of the calculation then we can set it to the empty string for TypeId calculation purposes.
    According to the XTypes spec:
    "To allow types to refer to one another unambiguously, a given TypeId value shall uniquely identify a type within the TypeLibrary contained by a TypeObject object and in any other Type Libraries contains recursively therein. It shall have no narrower scope. There is no restriction that a type's definition must occur a TypeId reference to it; there is no concept of a forward declaration in this Type Representation."
    Therefore, two types within the library should not contained the same TypeId.
    3.- Also, the serialization in BigEndian of the TypeObject is not guaranteed to be the same across different DDS vendors since the TypeObject itself is a mutable type and therefore it requires parametrized encapsulation for its members. The choice of extended versus not extended parameter encapsulation may be different across different DDS vendors.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    New TypeID computation algorithm

    The previous algorithm included in the specification is not implementable because it causes inadvertent recursive dependency of type-id on themselves. The new computation of the TypeId has been defined such that all vendors compute the same values for the same types. See section 7.3.4.1.2 in the specification document.

  • Updated: Thu, 22 Jun 2017 16:42 GMT
  • Attachments:

XML type description not orthogonal and not consistent

  • Legacy Issue Number: 18302
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The XML description of a type seems cumbersome and not orthogonal. I have lots of questions regarding it. Why do we propose 2 separate XML representations (Valid and Well-formed) that both have obvious flaws instead of 1 XML representation that satisfies the requirements of both representations? PrismTech has written an extensive proposal on how represent the types in XML that is both valid, well-formed and orthogonal. I would propose to give that proposal a thought. (Can't attach the document to this ticket, but I will gladly make it available. Angelo also has access to that document

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarified both xml data representations

    Resolutions applied: Added the revised text in section 7.4.2.2

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Type system severely underspecified

  • Legacy Issue Number: 18301
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    In section 7.3.4.1.2 it is specified how to calculate the type ID for a given type. However, this algorithm heavily depends on the Type layout presented in Appendix B, which is not further explained. I have lots of questions about this algorithm, and am wondering if alternative mechanisms should not be considered instead.

    1) Where does the hash that identifies the typeID of a constucted type come from?

    It states that it comes from the Big Endian CDR respresentation of the type, which is an IDL representation of the model specified in Appendix B. However, this data model is not further explained, and far from mature and orthogonal. It looks like we created a pretty ad-hoc type system rather than deriving one from a well-designed meta-model with a minimal set of powerful transformation primitives.
    There is a lot of existing documentation on how to set up a proper type-system. I suggest we consult some best-practices instead of re-inventing the wheel here.

    2)The basis of the TypeObject consists of 2 fields, each having their own sequence. How the 2 sequences correlate is not further explained. The only thing that is explained in section 7.6.2.2 is that the the_type member of the TypeObject contains all types associated with the corresponding entity (1 for reader/writer, more for topic). I think it would be better to take this sequence outside TypeObject and give Topic a sequence of TypeObjects instead.

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    TypeId algorithm proposed

    See RTI's TypeId proposal attached to Issue #7: TypeId calculation errors/corrections. TypeId computation has been unambiguously specified.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

TypeObject semantics underspecified and inconsistent

  • Legacy Issue Number: 18300
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Section 7.3.4.1 specifies that a TypeObject can include just a single TypeLibrary while in section 7.3.4.1.1 it is claimed that a TypeObject can recursively contain other TypeLibraries.

    Of course this is confusing: which is it?

    Also does a typeID need to be globally unique or just in the TypeLibrary in which it is contained?

    Finally, and even more important, since the TypeObject may recursively refer to other (existing) types by their typeID, it is difficult to communicate the meta-data to a node that has no a-priori knowledge about it. The current TypeObject representation is compact, but only able to check whether two existing representations are compatible. It can't be used to drive meta-data based tooling a logger or a service that connects the DDS to a database.

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Added clarification for TypeLibrary

    Added clarification in section 7.3.4.1 that a single TypeLibrary which may recursively contain more TypeLibrary objects

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Definition of "strongly assignable" seems to be used inconsitently

  • Legacy Issue Number: 18297
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    if strongly assignable according to section 7.2.4 means that both types should be mutable, then why is the union in Table 15 (section 7.2.4.5, fifth bullet in 2nd column) talking about strong assignability for a T1 that is final or extensible?

    • Probably the definition for strongly typed is flawed, and should be about NON-mutable types.

    Generally speaking, the overall wording of the subject regarding strong assignability could is causing more confusion than it is clearing things up, and could use some big improvement.

    Lots of usecases regarding this subject are underspecified, for example:

    • If a type T1 is assignable from a type T2, and T1 has a non-optional member that is not represented in T2, it takes the default (non-configurable) default.
      How can I see the difference between a T1 with a member, that happens to be the default, and a T1 without that member?
      Since 0 is a very common value, it does not seems like a good candidate for default in this case.
  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarified definition of strongly assignable

    Updated section 7.2.4 with clearer definition of strongly assignable. Also updated union_type in Table 15 section 7.2.4.5 Aggregation Types.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

TypeId union is missing NO_TYPE from the possible values of the discriminator

  • Key: DDSXTY12-3
  • Legacy Issue Number: 19263
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The TypeId union declaration in Annex B is missing the value NO_TYPE as one possible discriminator. In addition, the use cases for the usage of that value are not documented.
    Assuming that we add a TypeId paramater to the endpoint information in addition to the type object. See issue "Send TypeId independently of the TypeObject". In a situation in which no type object or type id paramaters are found, we could indicate that to the user by providing a NO_TYPE TypeId as part of the PublicationBuiltinTopicData or SubscriptionBuiltinTopicData.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merged with DDSXTY12-7

    Merged with issue DDSXTY12-7, which adds NO_TYPE case in _TypeId union.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Send TypeId independently of the TypeObject

  • Key: DDSXTY12-2
  • Legacy Issue Number: 19262
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    Sending large TypeObjects is often an issue in discovery. Often times, the complete TypeObjects are not necessary as TypeId might just do the trick when exact matches are expected. Therefore, sending just the typeid is a good optimization.

    Therefore, add new discovery parameter in Publication and Subscription BuiltInTopicData to send the TypeId independently of the type object.

    Two use cases:
    1. Even if we cannot find type object at least we can verify typeId
    2. Allow a separate mechanism to get the TypeObject. This will help to reduce bandwidth

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Incorporated new TypeId algorithm

    A new typeid computation algorithm was added in section 7.3.4.1.2. Updated built-in topics with an optional typeid field. See revised text for details.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Topic incosisstency only considered for incompatible types, not for incompatible qos

  • Legacy Issue Number: 18308
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    What if 2 topics have the same type, but different Qos? Would that still trigger an INCONSISTENT_TOPIC status or not? The spec does not say anything about this.

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    Discussed clarifications

    The TF discussed clarifications and no changes are needed.

    Currently, the spec is clear about when inconsistent_topic status is raised. Only type (typeobject when present otherwise typename) is considered before raising the inconsistent topic status. One possibility to incorporate QoS in the mix would be to create yet another kind of status for topics. Right now it has only one. For DR and DW, there’s already inconsistent_requested_qos and inconsistent_offer_qos statuses. May be the new status could be a variant of those. It can’t be any of those however because (1) TopicQoS does not contain all QoS (2) TopicListener is a separate inheritance branch and (3) offered/requested semantics are not knowable at topic level because we don’t know what kind of entity might be created (so we can’t do as good a job as we do for entity’s inconsistent_requested/offered_qos statuses.)

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Specification document cleanup

  • Key: DDSXTY12-1
  • Legacy Issue Number: 19261
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    1. Remove references to type signature in XType specification: The concept of type signature has been removed from the XTypes specification. See OMG Issue No: 16561. However there are still references to it in the latest spec.
    List of references:
    Figure 39 - Dynamic Type Support
    Annex D: DDS Built-in Topic Data Types - Remove references to equivalent_type_name and base_type_name from PublicationBuiltinTopicData, SubscriptionBuiltinTopicData and TopicBuiltinTopicData

    2. Replace the definition of the_type within TypeObject from TypeIdSeq to _TypeId:
    In the final version of "OMG Issue No: 16097" the spec allows association of one type to an endpoint to simplify implementations.
    However, the spec kept the member "the_type" as a sequence instead of going back to a single element.

    3. Error in IDL definition of TypeObject: Definition of MapType, SequenceType, and StringType and in Annex B is marked as EXTENSIBLE but it should be MUTABLE.

    4. The "type" member in SubscriptionBuiltinTopicData and PublicationBuiltinTopicData should have "DynamicType" type instead of "TypeObject"

    Proposed Solution: Make the suggested changes.

  • Reported: DDS-XTypes 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Incorporated corrections

    Document cleanup performed removing dangling elements and incorrect IDL structures.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Inconsistencies and missing items

  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    In Section 7.2.3, Table 12 in the rows for "Collection Types", "Enumerated Types", "String Types", and "Primitive Types" should state that "For these types the extensibility kind has no effect."

    In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.
    Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.

    In Annex B in the IDL comment for AppliedBuiltinMemberAnnotations refers to “@hash_id” as opposed to “@hashid”, which is the actual annotation name. Every reference to “@hash_id” should be modified to refer to "@hashid."

  • Reported: DDS-XTypes 1.1 — Thu, 16 Mar 2017 00:38 GMT
  • Disposition: Deferred — DDS-XTypes 1.2
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Thu, 6 Apr 2017 14:10 GMT

Not every application limits itself to only 1 representation of a topic

  • Legacy Issue Number: 18305
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Section 7.6.1 states that every component only uses 1 representation of a topic type.
    Some generic services (e.g. durability service or a logger) might discover a topic from another node but will still be able to handle all representations of it, without ever having type specific knowledge hardcoded into them.

  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    Corrected paragraphs:
    Typically, in application code, a topic is associated with a single type (as has always been the case in the [DDS] API) . Therefore, multiple API topics may correspond to (different views of) the same network topic. A given reader or writer endpoint is associated with one of them. See Section 7.6.3, “Local API Extensions”, for definitions of the programming interfaces that support this polymorphism.
    Generic services (e.g., logger, monitor) may discover a topic associated with one or more types. Such services may be able to handle all representations of the types, without ever having type specific knowledge hardcoded into them.

  • Updated: Sat, 7 Mar 2015 04:43 GMT

Semantics of overriding an attribute not clearly specified

  • Legacy Issue Number: 18299
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Is it allowed to have a parent and a child struct share an attribute with the same name?

    • In most OO-languages this is allowed.
    • However, in scenario's like type-refactoring this will cause huge problems.

    We should clearly specify whether or not this is allowed, and when allowed we should clearly describe the consequences.

  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    The paragraph 7.2.2.3.5.1 updated as follows:
    A structure can optionally extend one other structure, its “base_type.” In the event that there is a name or ID collision between a structure and its base type, the definition of the member in the former takes precedence the definition of the derived structure is ill-formed.

  • Updated: Sat, 7 Mar 2015 04:43 GMT

Typo

  • Legacy Issue Number: 18296
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Typo: 4rth paragraph: For the saMe of run-time efficiency -> For the saKe of run-time efficiency.....

  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    Corrected sentence: For the same sake of run-time efficiency …

  • Updated: Sat, 7 Mar 2015 04:43 GMT

Typo in opening sentence of section: Missing noun and verb

  • Key: DDSXTY11-9
  • Legacy Issue Number: 18294
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The opening sentence seems to be missing a noun and a verb. Probably what is meant is:

    System developers frequently require the ability to inject their own output into <code> that <is> produced by a Type Representation compiler.

  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    Corrected sentence: System developers frequently require the ability to inject their own text into the code produced by a Type Representation compiler.

  • Updated: Sat, 7 Mar 2015 04:43 GMT

Inconsistent extensibility kind for enumerations

  • Key: DDSXTY11-8
  • Legacy Issue Number: 16559
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification of the extensibility kind for enumeration types is inconsistent. Figure 10 in section 7.2.2.3.1, "Enumeration Types", indicates that the extensibility_kind of all enumeration types is FINAL. However, Table 11 in section 7.2.3, "Type Extensibility and Mutability", says, "Enumeration types may be final, extensible, or mutable on a type-by-type basis."

    Proposed Resolution:

    The assignability rules for enumerations already address different extensibility kinds, so we can preserve the more general statement from 7.2.3. Fix Figure 10.

  • Reported: DDS-XTypes 1.0 — Mon, 19 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    The assignability rules for enumerations already address different extensibility kinds, so we can preserve the more general statement from 7.2.3. Fix Figure 10.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

DynamicData interface of the Language Binding section

  • Key: DDSXTY_-26
  • Legacy Issue Number: 15418
  • Status: closed  
  • Source: Brookhaven National Laboratory ( Nikolay Malitsky)
  • Summary:

    First, thank you for this specification. It provides a systematic and comprehensive definition of the runtime type system which is important in the context of the next version of Experimental Physics and Industrial Control System (http://www.aps.anl.gov/epics/). Moreover, from my perspective, the conceptual idea of the dynamic container is more generic than DDS and EPICS and addresses other technologies, like AMQP. In this regard, I have several suggestions for the DynamicData interface of the Language Binding section, particularly, to scale down the number of methods from 270 to 30 and to replace the 'out' arguments with return values.

    At this time, we are working on the prototype of this variant based on the consolidation of several approaches, including DDS Dynamic Data, Google's Protocol Buffers, etc. Certainly, for us, it would be ideal to have some common solution. According to the Beta 1 procedure, OMG will accumulate comments by November 29. But, probably, it can be discussed earlier, for example, at the coming OMG technical meeting. Please advise.

  • Reported: DDS-XTypes 1.0b2 — Mon, 16 Aug 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    non issue, closed

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Inconsistent generated code for DynamicType::descriptor

  • Key: DDSXTY_-25
  • Legacy Issue Number: 17090
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    DynamicType has a property "descriptor" of type (read-only) TypeDescriptor. This property is mapped to IDL as a readonly attribute. When code is generated for this attribute in C or C++, the corresponding getter is not consistent with the other getters in the same class, either in terms of its style or in terms of its memory management. (The other getters are all defined explicitly as methods in IDL.)

    Proposed Resolution:
    Remove this member and add an explicit getter method:

    DDS::ReturnCode_t get_descriptor(
    inout TypeDescriptor descriptor);

    This method overwrites a user-provided object, just like get_member_by_name and get_annotation.

  • Reported: DDS-XTypes 1.0b2 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Remove these attributes and add explicit getter methods, like:
    DDS::ReturnCode_t get_descriptor(
    inout TypeDescriptor descriptor);
    This method overwrites a user-provided object, just like DynamicType::get_member_by_name and get_annotation

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Circular reference in definition of specialized Primitive Types

  • Key: DDSXTY_-24
  • Legacy Issue Number: 17023
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The specialized Primitive Types defined for Int, UInt, Float, Boolean, etc... each define a property 'value' that is typed by the property's owner thus resulting in a circular reference in the model.

    Figure 6
    Figure 7
    Figure 8

    Each of these are specializations of the PrimitiveType abstract class. Changing the UML instance of the PrimitiveType definition to a UML:PrimitiveType will automatically convey the semantic that an instance of the specialized PrimitiveType is the value itself.

    NB: To do this in Enterprise Architect recreate the PrimitiveType abstract definition as an instance of the 'Primitive' element found in the 'Class' toolbox.

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Remove the value members

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Introduce the notional value "null" that may be used in a content-filter expression

  • Key: DDSXTY_-19
  • Legacy Issue Number: 16720
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification introduces the concept of optional members into DDS data types. However, it does not address how comparisons of these members should work in content-filtering expressions. For example, if a content-filtered topic indicates that all samples are of interest where "x != 5", but x is not present in the sample at all, does the sample pass the filter or not?

    Proposed resolution: Introduce the notional value "null" that may be used in a content-filter expression. The null value is not equal to any value in the domain of any data type. (That is, x != null for any non-null value of x.) A member's value in a given sample shall be considered to be equal to null if that member is not present in the given sample. Its value shall not be considered equal to null if it is present.

  • Reported: DDS-XTypes 1.0b2 — Mon, 21 Nov 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Optional members:
    Introduce the notional value “null” that may be used in a content-filter expression. The null value is not equal to any value in the domain of any data type. (That is, x != null for any non-null value of x.)
    • An optional member’s value in a given sample shall be considered to be equal to null if that member is not present in the given sample.
    • Its value shall not be considered equal to null if it is present.
    • A non-optional member’s value shall never be considered equal to null.
    Maps:
    Use the same syntax as arrays and sequences, but instead of a numeric index, use the stringified representation of the key to be queried as a string literal. Such an expression evaluates to the “value” element of the map that is associated with the given key. For example:
    my_map['foo'] = 'bar'
    my_map['5'] = 'baz'
    Bit sets:
    Use the same syntax as arrays and sequences, but instead of a numeric index, use the enumerated constant identifying the desired bit. Such an expression evaluates to a Boolean value: true if the named bit is set or false if it is not. For example:
    my_bitset['MY_BIT_CONSTANT']
    Specify the above rules in a new section 7.6.5, “DCPS Queries and Filters”. Include the relevant updates to the DCPS Queries and Filters grammar (from Annex A in the DDS 1.2 specification).
    In addition, include a description of the following things that should be described in DDS already but seem to be missing:
    • The use square bracket syntax for arrays, strings, and sequences
    • Boolean literals
    An issue should be filed against DDS for this, but the resolution of this issue should not wait for it to be acted upon.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Invalid data types applied to AnnotationDescriptor::value, DynamicData::descriptor, DynamicData::value

  • Key: DDSXTY_-23
  • Legacy Issue Number: 17022
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The above-mentioned attributes (Figures 28 and 37) have types defined in the form "xxx --> yyy" which has no meaning in UML. Please clarify and correct.

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Change the type of AnnotationDescriptor::value to Map<String, String>.
    Unify the property DynamicData::descriptor with the existing association to MemberDescriptor, and qualify this association by MemberId.
    Change the property DynamicData::value to an association to Type, and qualify this association by MemberId.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Conflicting data types applied to several Attributes, Operations and Parameters in UML notation

  • Key: DDSXTY_-22
  • Legacy Issue Number: 17021
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The following figures exhibit inconsistent application of data types to attributes, operations and parameters:
    Figure 4
    Figure 9
    Figure 10
    Figure 13
    Figure 14
    Figure 16
    Figure 26
    Figure 30
    Figure 33
    Figure 36
    Figure 37
    Figure 38
    Figure 39

    Certain attributes/parameters have 'int' or 'string' applied which conflict the data types defined within the aforementioned model, and the PrimitiveTypes defined in UML. What is the intent with these? Which set of primitive data types are intended for application here (IDL? Java, C++, UML, XTypes?)

    For example, the 'Enumeration' class in Figure 10 defines a 'bit-bound' property of type int.

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Use DDS-XTypes types consistently. Note that Figures 9 and 16 are already correct—they use the DDS-XTypes-derived basic types, not the UML-built-in ones.
    Note that if the resolution to issue #16561 is accepted, the modification to figure 38 will be irrelevant, because the corresponding section of the document will be removed.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Non-standard UML notation on figures

  • Key: DDSXTY_-21
  • Legacy Issue Number: 17020
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The following figures exhibit non-standard notation for specialized elements:
    Figure 4
    Figure 9
    Figure 11
    Figure 14
    Figure 16
    Figure 17
    Figure 20

    The textual notation showing generalized elements on specialized ones needs to either be hidden, or have the generalized element explicitly shown on the diagram (with generalization relationship between the elements showing).

    NB: To hide the generalized element names on specialized ones in Enterprise Architect, double-click on a blank area of the diagram to open the Diagram Properties Dialog. On the "Diagram" tab deselect the "Show additional Parents" option.

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Figures 4, 6–9, 12, 13, 15, 16, 17, 20, and 38: Simply hide the additional parents, as described above. Note that if the resolution to issue #16561 is accepted, the modification to figure 38 will be irrelevant, because the corresponding section of the document will be removed.
    Figures 10, 11, and 14: Add class “Namespace” to the diagram.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Truncation of text in Figure 3

  • Key: DDSXTY_-20
  • Legacy Issue Number: 17019
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The first rectangular symbol in Figure 3 contains truncated text - Type Representation

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Fix the truncated text

  • Updated: Fri, 6 Mar 2015 21:48 GMT

New DDS-XTypes issue: inability to consume data using new base class

  • Key: DDSXTY_-18
  • Legacy Issue Number: 16561
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    have a new issue to file against the DDS-XTypes spec that was pointed out to me by Reinier Torenbeek.

    Declared compatibility of types (i.e. type signature) includes base types but not derived types. Unfortunately, that means that a consumer using a base class unknown to an existing producer will not be able to consume data from that producer, because neither party will declare the relationship between the types.

    For example: I publish Dog, which extends Animal. In version 2, a new intermediate class Mammal is introduced. However, a new consumer of Mammal won't match with a legacy producer of Dog, because both the Dog and Mammal endpoints declare that their types extend Animal, and neither one asserts that Dog should now extend Mammal.

    Proposed Resolution:

    Remove the type signature concept and go back to registering simple names. In its place, introduce a new QoS policy that lists assertions about which types extend which others. Consider making these assertions transitive. As today, the operative set of assertions when matching producers and consumers should be the union between the producer's and the consumer's sets.

  • Reported: DDS-XTypes 1.0b2 — Tue, 20 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Remove the type signature concept and go back to registering simple names

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Object assignability rules should be more resilient

  • Key: DDSXTY_-17
  • Legacy Issue Number: 16368
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    Source:

    RTI (Mr. Alejandro de Campos, alejandro@rti.com)

    Summary:

    A small object-level assignability problem within a complex sample can result in an entire sample being discarded. For example, a string whose length is greater than the bound of a string it’s being assigned into must be discarded. A sequence with an unassignable member must be discarded. A structure with an unassignable member must be discarded. As a result, a small issue deep within a structure could cause a whole sample to be discarded. For example, an issue within a TypeObject could result in an entire built-in topic data sample being discarded and consequently a loss of discovery information.

    Discussion:

    If we attempt to prevent any possible semantic problem that could arise from partial samples, we will have to keep the existing draconian rules, which can have bigger impacts, as described above. Therefore, the rules should seek to be more lenient and allow type-aware code “above” the assignability algorithm to detect semantic problems.

    Proposed Resolution:

    The following are the cases identified in the specification in which individual objects may be unassignable:

    · Strings that are too long: No change. Strings are a basic type, and truncation can generally not be easily detected by applications.

    · Arrays with unassignable elements: No change. In CDR, arrays have no length or other means of delimiting elements, so it is not possible to “truncate” them.

    · Sequences that are too long or contain unassignable elements: Discard only the offending elements, “left-shifting” subsequent elements and reducing the length as necessary.

    · Maps that are too long or contain unassignable elements: No change. Map entries are not logically ordered, so elements may not be discarded in a stable fashion.

    · Enumeration with unrecognized value: No change.

    · Union whose discriminator does not select a value in the destination type: No change—otherwise, the union would be malformed.

    · Structure with a “must understand” member not present in the destination type: No change—otherwise, the union would be malformed.

    Add the following new rules:

    · Structure with an unassignable non-optional member: The entire structure is considered unassignable. (This behavior was previously underspecified.)

    · Structure with an unassignable option member: The member takes no value. The rest of the structure can theoretically be retained.

  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    The following are the cases identified in the specification in which individual objects may be unassignable along with the changes to be made, if any:
    • Strings that are too long: If the bound of a string increases, the string is unassignable. Strings are a basic type, and truncation can generally not be easily detected by applications.
    • Arrays with unassignable elements: No change. In CDR, arrays have no length or other means of delimiting elements, so it is not possible to “truncate” them.
    • Sequences that are too long or contain unassignable elements: If the bound of a sequence increases, or an element is unassignable, the whole sequence is unassignable. Applications have little ability to detect or mitigate sequence truncation, so automatic truncation is undesirable.
    • Maps that are too long or contain unassignable elements: If the bound of a map increases, or an element is unassignable, the whole map is unassignable. Applications have little ability to detect or mitigate map truncation, so automatic truncation is undesirable.
    • Enumeration with unrecognized value: No change.
    • Union whose discriminator does not select a value in the destination type: No change—otherwise, the union would be malformed.
    • Structure with a “must understand” member not present in the destination type: No change—otherwise, the structure would be malformed.
    Add the following new rules for structures, which cover behavior that was previously underspecified:
    • An unassignable non-optional member: The entire structure is considered unassignable.
    • An unassignable optional member: The member takes no value. The rest of the structure can be retained.
    • Mismatched “optional” attribute in a final or extensible structure: The types are not assignable. This restriction is necessary because of the header that precedes such members.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Definition of “strongly assignable” is incomplete

  • Key: DDSXTY_-16
  • Legacy Issue Number: 16367
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The definition of the term “strongly assignable” in section 7.2.4, Type Compatibility: “is-assignable-from” relationship, states:

    If types T1 and T2 are both mutable and T1 is-assignable-from T2, then T1 is said to be “strongly” assignable from T2.

    The purpose of this concept is to distinguish cases where it is possible to delimit adjacent objects. This is necessary, for example, when deserializing arrays, to avoid a situation where extra members in an array element could throw off the deserialization of subsequent elements.

    This definition is overly restrictive and can even prevent arrays of non-mutable elements from being assignable to themselves.

    Proposed Resolution:

    Amend the definition to consider any type strongly assignable to itself.

    Proposed Revised Text:

    The definition of the term “strongly assignable” in section 7.2.4, Type Compatibility: “is-assignable-from” relationship, states:

    If types T1 and T2 are both mutable and T1 is-assignable-from T2, then T1 is said to be “strongly” assignable from T2.

    Append the following sentence:

    Any type is also considered (trivially) strongly assignable from itself, regardless of its extensibility kind.

  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Amend the definition of “strongly assignable” to consider any type strongly assignable to itself

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Incorrect default extensibility kind value in XSD file

  • Key: DDSXTY_-12
  • Legacy Issue Number: 16271
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    OMG Issue No: ?????

    Title: Incorrect default extensibility kind value in XSD file

    Source:

    RTI (Mr. Alejandro de Campos, alejandro@rti.com)

    Summary:

    The declaration of the complex type structOrUnionTypeDecl in the XSD file contains the following attribute declaration:

    <xs:attribute name="extensibility"

    type="extensibilityKind"

    use="optional"

    default="false"/>

    However, “false” is not a valid value for the extensibilityKind type.

    Proposed Resolution:

    Change the default value to “extensible”.

    Proposed Revised Text:

    Replace the following attribute declaration within the complex type structOrUnionTypeDecl:

    <xs:attribute name="extensibility"

    type="extensibilityKind"

    use="optional"

    default="false"/>

    …with this one:

    <xs:attribute name="extensibility"

    type="extensibilityKind"

    use="optional"

    default="extensible"/>

  • Reported: DDS-XTypes 1.0b2 — Mon, 23 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Change the default value to “extensible”.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Incorrect union assignability rules

  • Key: DDSXTY_-15
  • Legacy Issue Number: 16366
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The type assignability rules for unions have a number of problems (see the UNION_TYPE row of the table in section 7.2.4.5, Aggregation Types):

    · The second and third bullets in the list of rules are redundant.

    · According to the fourth bullet (assignability of default members), a union with a default label may not even be assignable to itself.

    · The rules do not account for member IDs and names, which can be significant when deserializing objects in some data representations.

    · The rules do not account for the fact that the discriminator may or may not be a key.

    · The rules do not account for extensibility kind.

    · The rules are under-specified with respect to malformed samples. Specifically, the discriminator may select a particular member X of the union, but the implementation may discover in its place a different member Y. (This situation will be detectable only with certain data representations.)

    Proposed Resolution:

    Apply the followin rules:

    · Apply the member ID, name, and type matching rules for structures to unions as well.

    · Every discriminator value in T2 must select the “same” member in T1—or no member at all. This can be checked in three steps:

    1. Every discriminator value in a non-default label of T2 selects the same member in T1 or none at all.

    2. Every discriminator value in a non-default label of T1 selects the same member in T2 or none at all.

    3. If both T1 and T2 have a default label, the corresponding members must be assignable.

    · Either both types must have a key or neither.

    · The extensibility kinds must match.

    · Specify explicitly that an object of a union with a mismatch between its discriminator and non-discriminator members is considered malformed. The impact is unspecified, although implementations may consider the object unassignable.

    Proposed Revised Text:

    Replace the center column of the UNION_TYPE row of the table in section 7.2.4.5, Aggregation Types, with the following:

    UNION_TYPE if and only if it is possible to unambiguously identify the appropriate T1 member based on the T2 discriminator value and to transform both the discriminator and the other member correctly. Specifically:

    · T1.discriminator.id == T2.discriminator.id and T1.discriminator.type is-assignable-from T2.discriminator.type.

    · Either the discriminators of both T1 and T2 are keys or neither are keys.

    · Any members in T1 and T2 that have the same name also have the same ID and any members with the same ID also have the same name.

    · For each member “m1” in T1, if there is a member m2 in T2 with the same member ID then m1.type is-assignable-from m2.type.

    · T1.extensibility == T2.extensibility.

    · A discriminator value appearing in a non-default label of T2 selects a member m2. If the same discriminator value selects a member m1 of T1, then m1.id == m2.id.

    · A discriminator value appearing in a non-default label of T1 selects a member m1. If the same discriminator value selects a member m2 of T2, then m1.id == m2.id.

    · If both T1 and T2 have a default label, then the IDs of the members selected by those labels must be equal.

    AND if T1 is final, the number of members in T1 is equal to the number of members in T2.

    Remove the footnote that is linked to the old contents of that table cell.

    Append the following paragraphs to the right-hand column of the same table row:

    If either member of the union is unassignable, then the T2 object is unassignable to T1.

    If the discriminator value of a union object and its non-discriminator member do not agree with one another, the object is considered malformed. In such a case, the behavior is unspecified. In particular, the implementation may or may not be able to detect this error. If it can, it should consider the object unassignable.

  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Apply the following rules:
    • Apply the member ID, name, and type matching rules for structures to unions as well.
    • Every discriminator value in T2 must select the “same” member in T1—or no member at all. This can be checked in three steps:
    1. Every discriminator value in a non-default label of T2 selects the same member in T1 or none at all.
    2. Every discriminator value in a non-default label of T1 selects the same member in T2 or none at all.
    3. If both T1 and T2 have a default label, the corresponding members must be assignable.
    • Either both types must have a key or neither.
    • The extensibility kinds must match.
    • Specify explicitly that an object of a union with a mismatch between its discriminator and non-discriminator members is considered malformed. If an implementation is able to detect this case, it shall consider the object unassignable. If not, then the impact is unspecified.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Inconsistent bit set/integer equivalency

  • Key: DDSXTY_-14
  • Legacy Issue Number: 16365
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    A bit set with bit bound <= 8 is mapped to a byte in some places (page 78 and 40) and to an unsigned short in others (page 88). (Page numbers refer to beta 2.)

    Proposed Resolution:

    A bit set with bit bound <= 8 should be serialized as a single byte.

    Proposed Revised Text:

    In the table in section 7.5.1.2.2, BitSet Types, replace these rows:

    Bit Set Bound
    Unsigned Integer Equivalent

    1–16
    unsigned short

    …with the following:

    Bit Set Bound
    Primitive Equivalent

    1–8
    octet

    9–16
    unsigned short

  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    A bit set with bit bound <= 8 should be serialized as a single byte.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Ambiguous description of serializing discovery types

  • Key: DDSXTY_-13
  • Legacy Issue Number: 16364
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The definition of PID_LIST_END in Table 27 in section 7.4.1.2.1, Interpretation of Parameter ID Values, reads:

    RTPS specifies that the PID value 1 shall be used to terminate parameter lists within the DDS built-in topic data types. Rather than reserving this parameter ID for all types, thereby complicating the member ID-to-parameter ID mapping rules for all producers and consumers of this Data Representation, Simple Discovery types only shall be subject to a special case: member ID 1 shall not be used, and either parameter ID 0x3F02 or parameter ID 1 shall terminate the parameter list.

    The meaning of “Simple Discovery types” is not clear. It should not apply to all mutable types that might ever be used as part of the Simple Discovery process. It is intended only to maintain backward compatibility with types defined in DDS-RTPS.

    Proposed Resolution:

    See the Proposed Revised Text below.

    Proposed Revised Text:

    Append an additional sentence: “These types consist of the built-in topic data types, and those other types that contain them as members, as defined by [RTPS].”

  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    See the Revised Text below

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Difficult to apply automation to statically defined types

  • Key: DDSXTY_-9
  • Legacy Issue Number: 16241
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Application code (i.e. business logic) generally depends statically on particular types and their members. Therefore, it is appropriate to define these types statically (e.g. in IDL) and generate code for them in order to take advantage of static type safety and improved performance.

    In contrast, infrastructure code (i.e. logic that is independent of particular applications) generally must not depend on application-specific types, because such dependencies prevent that code from being reused.

    These two kinds of code can exist within a single component. For example:

    · The properties of application-specific types might be checked against a common set of rules to ensure that they meet organizational or program-specific guidelines.

    · Certain design patterns may call for arbitrary application-specific types to be augmented in uniform ways.

    · Type-specific application activities, such as reading and/or writing data, might be logged or recorded.

    The straightforward way to handle these scenarios would be to:

    1. Convert a generated type definition into a DynamicType object.

    2. Convert an object of a generated type into a DynamicData object.

    3. Pass these two dynamic objects to the infrastructure code and allow it to operate on them.

    Unfortunately, the specification does not provide such a capability. Instead, applications have to manually construct DynamicType and DynamicData objects member by member. This code is not only verbose but also brittle, because if the static type definition changes (e.g. during development or across versions), it can grow out of sync with the hand-written code that manipulates that definition.

    Discussion:

    We need three new conversions:

    1. TypeSupport à DynamicType

    2. DynamicData à sample object

    3. Sample object à DynamicData

    These operations could either be added to the TypeSupport interface or to a “type builder” interface. The former approach is preferred, because the generic type parameter of the TypeSupport in the C++ and Java PSMs allows a degree of type safety that way.

    Proposed Resolution:

    Introduce three new TypeSupport operations:

    1. get_type: Get a DynamicType object corresponding to the TypeSupport’s data type.

    2. create_sample: Create a sample of the TypeSupport’s data type from an input DynamicData object. If the DynamicType of the DynamicData is not compatible with the TypeSupport’s data type, raise an error.

    3. create_dynamic_sample: Create a DynamicData object from an input sample of the TypeSupport’s data type.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Introduce three new TypeSupport operations:
    1. get_type: Get a DynamicType object corresponding to the TypeSupport’s data type.
    2. create_sample: Create a sample of the TypeSupport’s data type from an input DynamicData object.
    3. create_dynamic_sample: Create a DynamicData object from an input sample of the TypeSupport’s data type.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Changing a DynamicType object is ambiguous

  • Key: DDSXTY_-8
  • Legacy Issue Number: 16240
  • Status: closed  
  • Source: Brookhaven National Laboratory ( Nikolay Malitsky)
  • Summary:

    The current DynamicType API allows a type definition to be changed. Such a change can be ambiguous at best and dangerous at worst.

    · Suppose that the type already types (DynamicData) objects. Should all of those objects refer to the old version of the type or the new version? If the new version, how shall we address the situation where the new type is inconsistent with the existing data contents?

    · Suppose that the type has already been registered with some domain participant. Does the registered type name refer to the old version of the type or the new version? What shall be done about samples that may already have been published or received using the old version?

    · Can DynamicTypeFactory cache and reuse identical types that are requested more than once? Ideally yes, but the ability to change a type makes the state management necessary to support this behavior very complicated.

    It would be safer, clearer, and more efficient if DynamicType objects were immutable once created. That implies that either the factory must take sufficient inputs to fully create a type in one step, or we must employ a builder or similar pattern.

    Discussion:

    A builder pattern would give the application more flexibility in how to create new types. It would also nicely encompass the current load_type operations as well as hypothetical PSM-specific operations, such the creation of a DynamicType from a Java Class object.

    Proposed Resolution:

    TO DO

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Define a new class DynamicTypeBuilder as a copy of the current definition of DynamicType. Remove from DynamicType all operations that modify an object, and add to DynamicTypeBuilder an operation build that returns a corresponding (immutable) DynamicType.
    Update the existing DynamicTypeFactory to create instances of DynamicTypeBuilder instead of DynamicType. Rename this class DynamicTypeBuilderFactory accordingly.
    Replace the existing operation DynamicType::clone with a corresponding create operation in DynamicTypeBuilderFactory.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Optional, must_understand members of non-mutable aggregation types cannot be accurately represented in CDR

  • Key: DDSXTY_-11
  • Legacy Issue Number: 16243
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Members of a structure or union type have a small number of metadata attributes, among them:

    · optional: indicates that the member may or may not take a value in a particular sample

    · must_understand: indicates that a consumer of the data must discard the sample if it encounters such a field in it

    The type-level assignability rules detect mismatches respecting non-optional must_understand members. (Such members will always take a value, and therefore there is no possibility of data exchange between the producer and consumer.) However, must_understand members that are optional must be detected on a sample-by-sample basis: any sample that does not contain the offending member can be exchanged, but those that do cannot.

    The XML Data Representation allows the encoding of the must_understand attribute within each sample, as does the parameterized encapsulation variants of the Extended CDR Data Representation. However, the traditional, non-parameterized encapsulation variants—used by final and extensible structures and unions—do not permit this attribute to be expressed. As a result, consumers will not be able to detect when it should have been present, and may therefore present incorrect data to applications.

    Discussion:

    The traditional CDR encapsulations prefix each optional member with a 32-bit “header” that indicates the presence and size of the member. In contrast, the parameterized CDR encapsulations prefix each member with a 32-bit parameter header that indicates the presence, size, ID, and metadata flags of the member, including must_understand. Therefore, we can reuse the parameter header structure we already have to solve this problem, instead of using just a 32-bit size, with no increase in overhead.

    Proposed Resolution:

    Reorganize the Extended CDR Data Representation section such that it first defines the parameter header structure and the member-ID-to-parameter-ID mapping. Second it shall define the traditional encapsulation variants, and finally it shall define the (fully) parameterized encapsulation variants.

    Within the middle section—traditional CDR—update section 7.4.1.1.5.2, “Optional Members.” Remove the description of a 32-bit size, and in its place describe the use of a parameter header. Note that either the four-byte header defined by DDS-RTPS or the 12-byte extended header defined by DDS-XTypes may be used.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Update section 7.4.1.1.5.2, “Optional Members.” Instead of preceding each optional member with a 32-bit size, use a parameter header. Note that either the four-byte header defined by DDS-RTPS or the 12-byte extended header defined by DDS-XTypes may be used.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

New QoS policies don’t indicate whether they can be changed

  • Key: DDSXTY_-10
  • Legacy Issue Number: 16242
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Mr. Alejandro de Campos, alejandro@rti.com)

    Summary:

    Each DDS QoS policy must define a couple of attributes: whether or not the policy has request-offer (RxO) semantics and whether or not it can be changed after an entity is enabled. The two new QoS policies defined by DDS-XTypes—TypeConsistencyEnforcementQosPolicy and DataRepresentationQosPolicy—define the first part but not the second.

    Discussion:

    Because of their potential interactions with historical data, neither of these policies should be changeable after an entity is enabled.

    Proposed Resolution:

    State in the introduction to each policy that its value cannot be changed after an entity is enabled.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    State in the introduction to each policy that its value cannot be changed after an entity is enabled

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Typographical errors

  • Key: DDSXTY_-7
  • Legacy Issue Number: 16239
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification contains the following identified typographical errors:

    · The third bullet in section 2.2, “Network Interoperability Conformance”, which begins with “Data Representation…”, is lacking an opening parenthesis at the start of the second sentence. The closing parenthesis is already present.

    Proposed Resolution:

    See the trivial corrections described above.

    Proposed Revised Text:

    See the trivial corrections described above

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    See the trivial corrections described above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Type signature fields in built-in topic data shouldn't use unbounded strings

  • Key: DDSXTY_-6
  • Legacy Issue Number: 16238
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The type_name members of TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData are bounded at 256 characters. The equivalent_type_name and base_type_name members store sequences of type names, but the strings in those sequences are unbounded. The flexibility to store strings of any length is unnecessary, because no string can appear there that doesn’t also appear in a type_name somewhere, and is therefore of 256 characters or less.

    This issue is minor in that it does not impact correctness. However, it does impact clarity to a small extent and can impact the efficiency of some implementations.

    Proposed Resolution:

    Define a typedef “TypeName”, a string bounded at 256 characters. (See also issue #15969.)

    Define a typedef “TypeNameSeq”, an unbounded sequence of TypeName elements.

    Change the type of the equivalent_type_name and base_type_name members from StringSeq to TypeNameSeq.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    This issue is obsolete in the face of issue #16561: the resolution of that issue eliminates the type signature concept altogether. Therefore, this issue should be merged with that one.
    Disposition: Merged with issue #16561

  • Updated: Fri, 6 Mar 2015 21:48 GMT

No way to get or set length of collection-typed DynamicData objects

  • Key: DDSXTY_-5
  • Legacy Issue Number: 16237
  • Status: closed  
  • Source: Brookhaven National Laboratory ( Nikolay Malitsky)
  • Summary:

    A DynamicData object may encapsulate the state of an object of a collection type—a sequence, array, string, or map. In such a case, it is necessary to be able to get and set the length of the collection.

    Discussion:

    We need to add an accessor for the current length. This accessor can also be useful for other object of other types; for example, it can return the number of members in a structure.

    However, it is not appropriate to add a mutator for the length directly:

    · If the length of a collection is increased, that implies the addition of new elements. But the values of these new elements will not be meaningful.

    · If the length of a collection is decreased, that implies the removal of existing elements. But that may not be meaningful (what does it mean to remove a non-optional member of a structure?) of useful (why would you want to clear the fifth element of a bit set just because of what its index is?).

    · The lengths of some types cannot legally be changed at all—for example, array types.

    Therefore, it is better to allow elements to be added and removed, where appropriate, and thereby modify the length implicitly.

    Proposed Resolution:

    Add an operation get_length to the DynamicData class.

    · If the object is of a collection type, return the number of elements currently in the collection. In the case of an array type, this value will always be equal to the bound.

    · If the object is of a bit set type, return the number of named flags that are currently set in the bit set.

    · If the object is of a structure or annotation type, return the number of members in the object. This value may be different than the number of members in the corresponding DynamicType—for example, some optional members may be omitted; see the existing DynamicData documentation.

    · If the object is of a union type, return the number of members in the object. This value will always be two: the discriminator and the current member corresponding to it.

    · If the object is of a primitive or enumeration type, it is atomic: return one.

    · If the object is of an alias type, return the value appropriate for the alias’s base type.

    Expand the contracts of the existing set_<type>_value operations to allow them to append new elements to resizable collections—strings, sequences, and maps. (This behavior is aligned with the existing contract of the clear operations, which states that cleared elements of resizable collections shall be removed.) Obtain the member ID associated with the new value as follows:

    · For a string or sequence type, use get_member_id_at_index to obtain an ID for the index one greater than the current length.

    · For a map type, use get_member_id_by_name to obtain an ID for the new map key.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Add an operation get_item_count to the DynamicData class.
    • If the object is of a collection type, return the number of elements currently in the collection. In the case of an array type, this value will always be equal to the product of the bounds of all array dimensions.
    • If the object is of a bit set type, return the number of named flags that are currently set in the bit set.
    • If the object is of a structure or annotation type, return the number of members in the object. This value may be different than the number of members in the corresponding DynamicType—for example, some optional members may be omitted; see the existing DynamicData documentation.
    • If the object is of a union type, return the number of members in the object. This value will always be two: the discriminator and the current member corresponding to it.
    • If the object is of a primitive or enumeration type, it is atomic: return one.
    • If the object is of an alias type, return the value appropriate for the alias’s base type.
    Expand the contracts of the existing set_<type>_value operations to allow them to append new elements to resizable collections—strings, sequences, and maps. (This behavior is aligned with the existing contract of the clear operations, which states that cleared elements of resizable collections shall be removed.) Obtain the member ID associated with the new value as follows:
    • For a string or sequence type, use get_member_id_at_index to obtain an ID for the index one greater than the current length.
    • For a map type, use get_member_id_by_name to obtain an ID for the new map key.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Annex D (“DDS Built-in Topic Data Types”) is out of sync with IDL file

  • Key: DDSXTY_-4
  • Legacy Issue Number: 16236
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The equivalent_type_name and base_type_name fields from TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData are described in the prose of the specification and are reflected in the IDL file. However, they missing from the annex; they need to be added.

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    • Replace all literal-formatted text in Annex A (beginning with “<?xml…”) with the contents of the XSD file accompanying the specification.
    • Replace all literal-formatted text in Annex B (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex C (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex D (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex E (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex F (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

C++ mapping MAP type needs member access semantics specification

  • Key: DDSXTY_-3
  • Legacy Issue Number: 15981
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The C++ mapping for the new MAP type needs a precise specification of member (or key) access semantics and memory management rules like the CORBA C++ mapping describes for the SEQUENCE type on pages 36-42 (par. 4.15) of the C++ language mapping, version 1.2, formal/2008-01-09.

  • Reported: DDS-XTypes 1.0b2 — Mon, 24 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Close this issue without making any change.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Restrictions on MAP key element type not (clearly) documented/specified

  • Key: DDSXTY_-2
  • Legacy Issue Number: 15976
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    Allthough the specification of the MAP_TYPE in paragraph 7.2.2.3.4 refers to restrictions for key element type this is not formalized in either the specification for the IDL representation for maps or the C++ language mapping.

    It should be clearly noted (for the IDL representation in bnf) that the key element type is restricted to integer and string types only.

    The current IDL representation specs for map leave all options open for defining the key element type.
    Although the specs in paragraph 7.2.2.3.4 describe the use of other element types as 'behaviour undefined' this is not clear enough as the chosen C++ representation simply will not work when f.i STRUCT or UNION types are chosen as key element type.

  • Reported: DDS-XTypes 1.0b2 — Fri, 21 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    In section 7.2.2.3.4, provide a rationale for the restriction on key types.
    In the section on the Plain Language Binding for map types (7.5.1.3), clarify that the use of an unsupported key element type shall result in a compilation error. Further indicate that in C++ (section 7.5.1.3.1), the Compare function implementation shall consider the character contents of strings; it shall not compare pointer values.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Anonymous types should not be used in IDL examples and the TypeObject representation IDL

  • Key: DDSXTY_-1
  • Legacy Issue Number: 15969
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    IDL Anonymous type declarations should not be used in IDL examples and the 'dds_xtypes.idl' file as this form of type declaration has been deprecated by the latest CORBA specs and will cause compatibility problems with modern CORBA IDL compilers.

  • Reported: DDS-XTypes 1.0b2 — Tue, 18 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    • In the definitions of GroupDataQosPolicy, TopicDataQosPolicy, and UserDataQosPolicy, replace sequence<octet> with ByteSeq. This change removes occurrences of an anonymous type inherited from DDS itself.
    • In the definitions of TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData, replace the type of the name, topic_name, and type_name fields (string<256>) with the existing typedef ObjectName. This change removes occurrences of an anonymous type inherited from DDS itself.
    • In the definitions of Bytes and KeyedBytes, replace sequence<octet> with ByteSeq.
    • Introduce two typedefs: “VerbatimLanguage” and “VerbatimPlacement”, the first a string bounded at 32 characters and the second at 128 characters. Change the type of the member Verbatim::language to VerbatimLanguage and the type of Verbatim::placement to VerbatimPlacement.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Different applications in the same domain may associate the same Topic with different types

  • Key: DDSXTY-29
  • Legacy Issue Number: 16097
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Based on the DDS-XTypes specification, different applications in the same domain may associate the same Topic with different types. As a result through discovery it should be possible to find all such definitions. However this is not currently possible with the DDS v1.2 specification and the DDS-XTypes does not provide an extension for this API.

  • Reported: DDS-XTypes 1.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    The following resolution is related to the resolutions of issues #15702, #16007, and #16720.
    Abstract Model:
    A given topic is associated with one or more types. (This is a “topic” in the “virtual” system-wide sense independent of the way a topic is reflected through the API to any given component.) A given writer or reader endpoint is associated with one of the types of its topic.
    If a writer and a reader share the same topic, then it is assumed that they are intended to communicate with one another. At that point, the two endpoints are evaluated to make sure that they are type-compatible—see the resolution to issue #15702.
    On the Network:
    The Topic, Publication, and Subscription built-in topic data types already contain a type_name member. In addition, these data types shall contain a list of type definitions encapsulated in a TypeObject (defined in the resolution to issue #15702). In the Publication and Subscription cases, this “list” shall consist of only a single element. In the Topic case, it may consist of multiple elements.
    There is a related issue that will be addressed in the context of this issue, because it will improve matching performance and prepare the specification for the possibility of future support for polymorphic readers and writers: Today, the TypeObject type representation is not amenable to compact representation or fast comparison: types are identified by a “type ID” that an implementation can generate any way that it wishes. This approach has two weaknesses: (1) A definition is not self-contained—it requires a full tree of the types it uses to also be present. Also, (2) two types may be logically “equal” but may not have the same binary representation, because they refer to the “same” types by different indexes. Therefore, modify the TypeObject representation to replace ad hoc type indexes with deterministic hashes. (The lower-order 64-bits of an MD5 hash of the TypeObject representation of the type is sufficient: a system would require 1e6 types before it would have a 1e-6 probability of a collision. A full 128-bit hash could be used, but the overhead would be significant when data sample sizes are very small.) This change will address both of the above issues. It will also allow implementations to flexibly truncate the amount of detail they put on the network. The overhead can be further reduced if we assume that most members will be of primitive type—we can define a type ID as a union of a (small) primitive type ID and a (hashed, big) complex type ID.
    In the Application Code:
    As always, a Topic object is not the real virtual topic—it is only a local proxy. We retain the constraint that a single local Topic object is associated with only a single type. This constraint keeps the programming model the same for both XTypes-supporting and non-XTypes-supporting implementations, and it keeps the mental model simple for the majority of applications, which will not be aware of the presence of multiple types in their topics.
    To allow endpoints of the same virtual topic to be associated with different types, we make one change: The names of local Topic objects do not need to be unique within a given DomainParticipant, provided that all of those Topics of the same name really represent different slices of the same virtual topic—in other words, they must all have the same name.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS-XTypes @Key annotation Issue

  • Key: DDSXTY-28
  • Legacy Issue Number: 16007
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The @key annotation is currently defined as:

    @Annotation
    local interface Key

    { attribute boolean value default true; }

    ;

    Now suppose I have the following topic type:

    struct ATopicType

    { string a; @Key @ID(20) long b; long c; @Key @ID(10) }

    ;

    What is the key (a,b) or (b,a)? What if there were no annotations?

    The order of the key should be formally defined by the spec as this has an impact, among other things, on the computation of the keyhash.

    The rule could be as simple as taking the key element in the same order of the attribute ID. The other option is to extend the key to support a value, yet I think the first alternative is more orthogonal.

  • Reported: DDS-XTypes 1.0b1 — Wed, 2 Feb 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    The key hash is currently calculated in the following way, according to the DDS-RTPS specification:
    1. Serialize the key members…
    a. …in their declaration order
    b. …in big-endian CDR format
    2. If the serialization is less than or equal to 128 bits, that is the key hash.
    3. Otherwise, apply an MD5 hash to reduce the result to 128 bits.
    Update step (1a) above such that key fields are always serialized in ascending order by member ID rather than by declaration order. Note that this change applies only when calculating the key hash, not at any other time.
    This change is backwards compatible with pre-XTypes DDS implementations, because legacy type definitions will lack @ID annotations, and hence all members will always be in ascending ID order.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can’t initialize TypeId from TypeKind

  • Key: DDSXTY-8
  • Legacy Issue Number: 15688
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    In the IDL definitions for the specification section Representing Types with TypeObject, the type TypeKind is declared to be an enumeration. The type TypeId is declared to be a typedef to long. Certain well-known TypeId values are initialized using TypeKind values. However, this causes compilation errors from some IDL compilers, which do not allow enumerated values to be assigned to integral constants.
    Resolution:
    Change TypeKind from an enumeration to a typedef to short.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Identifiers TypeId and Module collide with IDL keywords

  • Key: DDSXTY-9
  • Legacy Issue Number: 15689
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    In the IDL definitions for the specification section Representing Types with TypeObject:
    • The type “TypeId” collides with the IDL keyword “typeid.”
    • The type “Module” and its member “module” collide with the IDL keyword “module.”
    These collisions cause IDL compilation errors.
    Resolution:
    Escape the identifiers TypeId and Module by preceding them with underscores. Per the IDL specification, this lexical change does not impact the generated code.
    Rename the type member “module” to “mod” to prevent collisions either with the IDL keyword or with the name of the enclosing type.
    Revised Text:
    Replace the type identifier “TypeId” in the IDL file with “_TypeId” everywhere it occurs.
    Replace the type identifier “Module” in the IDL file with “_Module” everywhere it occurs.
    Replace the member identifier “module” (in the type “Module”) in the IDL file with “mod.”

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Don’t require CORBA namespace for primitive types in Plain Language Binding

  • Key: DDSXTY-23
  • Legacy Issue Number: 15703
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The Plain Language Binding relies on the IDL-to-C and IDL-to-C++ language mappings to generate programming APIs for these languages. Unfortunately, these mappings prefix all primitive type names with “CORBA,” which is incorrect and confusing for DDS users. For example:
    • DDS Int32 will become CORBA_Long in C.
    • DDS Float64 will become CORBA::Double in C++.
    Resolution:
    Update the Plain Language Binding for primitive types in C and C++ to place them in a conceptual “DDS” module instead of the current “CORBA” module. At the same time, rename them to be consistent with their names in the DDS type system—for example, “Int32” instead of “Long.” (The Plain Language Binding already makes several extensions to the IDL-to-C/C++ mapping specifications. This change would constitute one more.)
    These new primitive types must be compatible in size and representationwith the definitions in the Type System; these definitions will be provided in a table within the Plain Language Binding section. (As a side effect, they will also be compatible with to their CORBA-module counterparts, such that applications using both DDS and CORBA can assign from one to the other without type casts or loss of information.)

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Update the Plain Language Binding for primitive types in C and C++ to place
    them in a conceptual “DDS” module instead of the current “CORBA” module. At
    the same time, rename them to be consistent with their names in the DDS type
    system—for example, “Int32” instead of “Long.” (The Plain Language Binding
    already makes several extensions to the IDL-to-C/C++ mapping specifications.
    This change would constitute one more.)
    These new primitive types must be compatible with the definitions in the Type
    System; these definitions will be provided in a table within the Plain Language
    Binding section. (As a side effect, they will also be compatible with their CORBAmodule
    counterparts, such that applications using both DDS and CORBA can
    assign from one to the other without type casts or loss of information.)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allow more flexible type consistency enforcement

  • Key: DDSXTY-22
  • Legacy Issue Number: 15702
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Summary:
    Section 7.6.1.3.1, TypeConsistencyEnforcementQosPolicy: Conceptual Model, identifies the type consistency enforcement kinds. This QoS policy is request-offer (RxO); readers and writers must match exactly in order to communicate. However, this requirement for an exact match is not required by implementations and is too restrictive for users.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    The resolution below is closely related to the resolutions of issues #16097 and #16561.
    The existing type consistency enforcement QoS policy, which governs both type signature consistency and type definition structural consistency, shall be simplified. It shall be removed from the Topic and DataWriter QoS and the corresponding built-in topic data types. It shall remain in the DataReader QoS and in the Subscription built-in topic data type. Its “kind” enumeration shall have the following values:
    • DISALLOW_TYPE_COERCION: The DataWriter and the DataReader must support the same data type in order for them to communicate.
    • ALLOW_TYPE_COERCION: The DataWriter and the DataReader need not support the same data type(s) in order for them to communicate as long as the reader’s type is assignable from the writer’s type.
    The default settings shall be as follows:
    • For compliant readers: ALLOW_TYPE_COERCION
    • Inferred for non-compliant readers: DISALLOW_TYPE_COERCION
    Type compatibility shall be determined according to the following steps:s
    1. The TypeObject type definition is considered first, provided that it is available for both the Publication and the Subscription. (This is anticipated to be the most common case for DDS-XTypes-conformant implementations.) If the Subscription allows type coercion, then its type must be assignable from the type of the Publication. If the Subscription does not allow type coercion, then its type must be equal to that of the Publication.
    2. If either the Publication or the Subscription does not provide any TypeObject definitions, then the type names are consulted. (This case is important in cases where a given component cannot, or does not wish to, provide concrete type definitions. For example, it may not support XTypes, it may wish to conserve bandwidth, it may not wish to reveal its type definition(s), or it may not even be type-aware—it may simply record binary payloads, for example.) The Subscription and Publication type_name fields must match exactly.
    If the reader and writer are not type-compatible, the middleware raises an INCONSISTENT_TOPIC status change.
    The following behaviors will result from the default values and evaluation orders above when writers and readers have default QoS:
    • Compliant writers will communicate with compliant readers. The reader will allow type coercion. This behavior is what we want, and it is unchanged from the current DDS-XTypes default.
    • Compliant writers will communicate with non-compliant readers. The reader will not allow type coercion, so the types (really the type names) must match exactly. This behavior is unchanged from the implied contract of DDS implementations prior to DDS-XTypes.
    (Suppose the writer has out-of-band knowledge of the reader’s type definition. If the writer determines that the types are not equal, it will consider the topic inconsistent and forbid communication. The reader will be unable to detect this inconsistency. However, the reader will not receive any data from the writer, so deserialization errors will be prevented just the same.)
    • Non-compliant writers will communicate with compliant readers. The reader will allow type coercion. This behavior provides maximum flexibility without requiring changes to deployed non-compliant applications.
    (Suppose the reader has out-of-band knowledge of the writer’s type definition. If the reader determines that the types are not assignable, the writer will be unable to detect this inconsistency and may send data to the reader nonetheless. The reader implementation will need to detect and eliminate this extraneous data without attempting to deserialize it—for example, by checking upon receiving the data from the socket whether the source data is actually from a matched writer. This edge case is little different from other preexisting cases, such as the use by a non-matching writer of a multicast address used by the reader. Therefore, it is not expected to be a barrier to implementation.)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical errors

  • Key: DDSXTY-21
  • Legacy Issue Number: 15701
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification contains the following typographical errors:
    • Section 7.6.1.3.1, TypeConsistencyEnforcementQosPolicy: Conceptual Model, bullet EXACT_NAME: “…they’re structural definitions…” should be “…their structural definitions….”
    Resolution:
    Fix the errors as described above.
    Revised Text:
    Revisions are described in the summary above

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Fix the errors as described above.
    Note that the typo is section 7.6.1.3.1 will be addressed automatically by the resolution to issue #15702, which replaces the text is question. If no further typos are added to this issue, it can be closed as a duplicate of that issue.
    Revised Text:
    Revisions are described in the summary above.
    Disposition: Merged with issue 15702

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mutable structures with an empty intersection should not be considered assignable

  • Key: DDSXTY-20
  • Legacy Issue Number: 15700
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The type assignability rules for structure types (section 7.2.4.5, Aggregation Types) allow mutable types to be assigned in either direction, so long as there are no name, ID, or type conflicts among the types’ members. Unfortunately, these rules permit a degenerate case: two mutable types having no key members and no members in common will have no conflicts, and therefore will be considered assignable. However, readers will always observe every sample to have all default/empty contents.
    Resolution:
    Add an additional rule to the assignability determination to require that at least one member is in common.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add an additional rule to the assignability determination to require that at least
    one member is in common.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML representations should define namespaces

  • Key: DDSXTY-19
  • Legacy Issue Number: 15699
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Currently, the XML Type Representation and XML Data Representation do not define XML namespaces. This omission prevents XML documents of these types from being used in certain contexts, such as within XML catalogs or SOAP messages.
    Resolution:
    1. Specify the XML namespace for the XML Type Representation. This namespace shall be formed by appending the OMG document number of the specification to the OMG HTTP domain in the following way: http://www.omg.org/<TF or TC>/<year>/<month>/<document ordinal>/<section_name>. For example, the namespace for the beta 1 specification would be: http://www.omg.org/ptc/2010/05/12/XML_Type_Representation.
    2. Allow the association of a target namespace with the XSD Type Representation of a set of types, such that documents conforming to such type definitions may be properly validated against that namespace. This target namespace will be implied by the fully qualified name of each non-nested type, such that all DDS types, regardless of which Type Representation was used to define them, implicitly define a target namespace that can be used to validate XML Data Representation documentsThis mechanism will be specific to the XSD Type Representation; the concept of a target XML namespace will not be promoted into the Type System (or, by extension, into other Type Representations). (This implied target namespace will be a URN, not a URL; it will not be possible to dereference it.)
    2.3. Allow applications the choice of whether to include XML namespaces on the network. Split the XML Data Representation into two dialects: XML_VALID and XML_WELL_FORMED. The former will include explicit namespace declarations and properly qualify all element and attribute names. The latter will, for the sake of compactness, omit namespace information.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    1. Specify the XML namespace for the XML Type Representation. This
    namespace shall be formed by appending the OMG document number of the
    specification to the OMG HTTP domain in the following way:
    http://www.omg.org/<TF or TC>/<year>/<month>/<document
    ordinal>/<section_name>. For example, the namespace for the beta 1
    specification would be:
    http://www.omg.org/ptc/2010/05/12/XML_Type_Representation.
    2. Allow the association of a target namespace with the XSD Type
    Representation of a set of types, such that documents conforming to such
    type definitions may be properly validated against that namespace. If this
    target namespace is not specified explicitly, it shall be implied by the fully
    qualified name of each module, such that all DDS types, regardless of which
    Type Representation was used to define them, implicitly define a target
    namespace that can be used to validate XML Data Representation
    documents. The implied namespace shall take the form
    ddstype://www.omg.org/<module path>, where <module path> is a
    list of enclosing modules, separated by forward slashes, from outermost to
    innermost. (Note that this implied target namespace is a URN, not a URL; it
    will not be possible to dereference it.)
    3. Allow applications the choice of whether to include XML namespaces on the
    network. Split the XML Data Representation into two dialects: “valid” and “well
    formed.” The former will include explicit namespace declarations and properly
    qualify all element and attribute names. The latter will, for the sake of
    compactness, omit namespace information.
    With respect to (#2), the ability of an XSD author to explicitly specify a target
    namespace—rather than relying on a module-based implied namespace—is
    important to retain compatibility with the CORBA to WSDL/SOAP Interworking
    Specification, on which the XSD Type Representation depends. The authors of
    that specification explicitly chose not to support module-based namespaces for
    performance reasons, as described in section 4.1.4 of that specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide minimal backwards-compatible conformance point

  • Key: DDSXTY-25
  • Legacy Issue Number: 15705
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    One of the reasons for the development of the DDS-XTypes specification was the prior lack of explicitness and formality in the DDS type system and in its representations. DDS-XTypes addresses this need—and simultaneously extends both the type system and its representations. It would help the discourse about DDS systems, and the modeling of DDS systems, if a subset of DDS-XTypes were defined that identified only those parts of DDS and/or DDS-RTPS that were in broad use before the existence of DDS-XTypes.
    This subset would include the following:
    • A subset of the Type System:
    o The full set of primitive types
    o Strings of narrow or wide characters
    o Sequences
    o Aliases
    o Structures without inheritance and with “final” extensibility
    o Enumerations
    o Unions
    • The IDL Type Representation of the above
    • The CDR Data Representation of the above
    • The Plain Language Binding for the above

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Identify the above subset of the specification in a new, non-normative, annex

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide formal grammar for new IDL Type Representation constructs

  • Key: DDSXTY-24
  • Legacy Issue Number: 15704
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL Type Representation defines syntax for Type System concepts that were previously not expressible in IDL, such as annotations, maps, etc. This syntax is currently defined in prose and with examples. The specification should additionally provide a formal EBNF grammar.
    Resolution:
    Add EBNF grammar constructs to the relevant sections of the specification document.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add EBNF grammar productions to the relevant sections of the specification document.
    To avoid whitespace sensitivity in these productions, modify the Alternative (comment-like) Syntax when multiple annotations are applied. Instead of writing this:
    //@MyFirstAnnotation @MySecondAnnotation
    …write this:
    //@MyFirstAnnotation //@MySecondAnnotation

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improve support for shared data

  • Key: DDSXTY-27
  • Legacy Issue Number: 15707
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The Type System currently allows a type designer to specify that the storage for a type member may be located outside of the type itself. (This is an important capability when, for example, objects of the member’s type are very large.) However, it provides insufficient flexibility when such objects are stored in collections: the entire collection may be stored externally, but the collection members must be stored contiguously.
    Resolution:
    Enhance the Type System to allow collection elements to be shared, not just members of aggregation types. In the IDL Type Representation, this shall be expressed syntactically by the application of the built-in @Shared annotation to the collection member type.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Enhance the Type System to allow collection elements to be shared, not just members of aggregation types. In the IDL Type Representation, this shall be expressed syntactically by the application of the built-in @Shared annotation to the collection member type.
    Note that this resolution does not provide a general-purpose annotation facility for collection members. It merely provides an appropriate Type System property and Type Representation syntax to express it.
    Sequences:
    sequence<@Shared Foo, 42> sequence_of_foo;
    // or:
    sequence<
    Foo, //@Shared
    42
    > sequence_of_foo;
    Arrays:
    Foo array_of_foo @Shared [42];
    // or:
    Foo array_of_foo //@Shared
    [42];
    Maps:
    map<string, @Shared Foo, 42> map_of_string_to_foo;
    // or:
    map<
    string,
    Foo, //@Shared
    42
    > map_of_string_to_foo;
    Strings: Strings will not support this feature (i.e. individual characters cannot be stored externally to the string itself). Since string elements can only be individual narrow or wide characters, this “limitation” in theory is not expected to be a limitation in practice.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reduce size of DynamicData API

  • Key: DDSXTY-26
  • Legacy Issue Number: 15706
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The DynamicData class, part of the Dynamic Language Binding, has a huge API consisting of many dozens of methods. This large size makes the API harder to understand and reuse.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Change the design of the class to reduce the size of the API. Specifically:
    • Replace navigation by name, ID, or index with navigation by ID only. Provide conversion methods to obtain the ID based on either of the other two. When the object is of some type for which the concept of “member ID” is not applicable (e.g. sequences), the user can nevertheless convert from the index to a “member ID” and look up based on that. It is not necessary to specify the mapping from index to ID in such cases; all that matters is that the implementation can provide one. (Where the range of indexes and IDs overlap, the “mapping” could even be a no-op.)
    • Coalesce access to sequences and arrays.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect FooDataWriter overloads for built-in types

  • Key: DDSXTY-16
  • Legacy Issue Number: 15696
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL file contains specializations of all of the type-specific interfaces for the new built-in types: “Foo”DataWriter and “Foo”DataReader. Some of these specializations contain additional “overloads” of DDS-standard types-specific methods for the sake of convenience. However, some of these overloads are not correct:
    • KeyedStringDataWriter::unregister_instance_w_key does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance method specified by DDS.)
    • KeyedStringDataWriter::unregister_instance_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance_w_timestamp method specified by DDS.)
    • KeyedStringDataWriter::dispose_w_key does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose method specified by DDS.)
    • KeyedStringDataWriter::dispose_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose_w_timestamp method specified by DDS.)
    • BytesDataWriter::write_string_w_bytes should be named BytesDataWriter::write_w_bytes (copy-paste error).
    • BytesDataWriter::write_string_w_bytes_w_timestamp should be named BytesDataWriter::write_w_bytes_w_timestamp (copy-paste error).
    • KeyedBytesDataWriter::unregister_instance_w_key does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance method specified by DDS.)
    • KeyedBytesDataWriter::unregister_instance_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance_w_timestamp method specified by DDS.)
    • KeyedBytesDataWriter::write_bytes_w_key doesn’t actually include the key among its arguments. It should.
    • KeyedBytesDataWriter::write_bytes_w_key_w_timestamp doesn’t actually include the key among its arguments. It should.
    • KeyedBytesDataWriter::dispose_w_key does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose method specified by DDS.)
    • KeyedBytesDataWriter::dispose_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose_w_timestamp method specified by DDS.)
    Resolution:
    Correct the method signatures as described in the summary above.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Correct the method signatures as described in the summary above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing definitions of TypeSupport specializations for built-in types

  • Key: DDSXTY-15
  • Legacy Issue Number: 15695
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL file contains specializations of all of the type-specific interfaces for the new built-in types: “Foo”DataWriter and “Foo”DataReader. However, the FooTypeSupport definitions are not included. These specializations require no method overloads; however, they should be included for the sake of clarity and completeness.
    Resolution:
    Add the missing type definitions.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add the missing type definitions

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allow IDL compatibility pragma declarations to nest

  • Key: DDSXTY-18
  • Legacy Issue Number: 15698
  • Status: closed  
  • Source: Jackrabbit Consulting ( Dr. Robert (Nick) Stavros)
  • Summary:

    Section 7.3.1.1.2, Forward Compatibility with Respect to Compilers, defines a pragma declaration that IDL file authors can use to delimit portions of their IDL files that require certain versions of this specification. Especially since IDL files can include one another, it would be helpful if such pragma declarations were allowed to nest within one another.
    Resolution:
    Allow pragma declarations to nest.
    • Any version number specified by a nested pragma overrides the enclosing version number, if any.
    • Any unclosed declaration shall be considered to continue until the end of the input.
    In addition, the pragma “end” declaration shall—like the “begin” declaration—allow a version number to be specified to clarify the nesting relationship.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Allow pragma declarations to nest.
    • Any version number specified by a nested pragma overrides the
    enclosing version number, if any.
    • Any unclosed declaration shall be considered to continue until the end of
    the input.
    In addition, the pragma “end” declaration shall—like the “begin” declaration—
    allow a version number to be specified to clarify the nesting relationship.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consolidate IDL built-in annotations in machine-readable file

  • Key: DDSXTY-17
  • Legacy Issue Number: 15697
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification provides equivalent definitions for the built-in annotations defined by the IDL Type Representations. However, it only includes these in the specification document, not in the IDL file.
    Resolution:
    Add these definitions to the IDL file. Add this content as an additional annex in the specification document.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add these definitions to the IDL file. Add this content as an additional annex in
    the specification document

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Updated QoS definitions should be provided

  • Key: DDSXTY-14
  • Legacy Issue Number: 15694
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification dictates that the new QoS policies DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy apply to Topics, DataReaders, and DataWriters. These additions are reflected in the IDL file by the inclusion of corresponding members in the built-in topic data types TopicBuiltinTopicData, SubscriptionBuiltinTopicData, and PublicationBuiltinTopicData. Corresponding additions to TopicQos, DataReaderQos, and DataWriterQos are therefore implied, but updated definitions of those types are not provided in the IDL file.
    Resolution:
    Add the missing type definitions to the IDL file.
    The type extensibility kinds of the QoS structures should be MUTABLE to be consistent with the built-in topic data types, which are also containers of QoS policies and which have that extensibility kind.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add the missing type definitions to the IDL file.
    The type extensibility kinds of the QoS structures should be MUTABLE to be
    consistent with the built-in topic data types, which are also containers of QoS
    policies and which have that extensibility kind.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extensibility kinds of new QoS policies are not specified in a consistent way

  • Key: DDSXTY-13
  • Legacy Issue Number: 15693
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL file augments the DDS-standard QoS policies with meta-data defined by this specification in a way that is consistent with the serialization of those policies as defined by the DDS-RTPS specification. Specifically, it defines each policy to be “nested” (meaning that it is intended to be propagated only when contained within another type) to have an extensibility kind of EXTENSIBLE (meaning that members can be appended to the end of the type, but that members cannot be inserted in the middle or reordered).
    In contrast, the two new QoS policies introduced by the specification—DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy—are defined to be nested, but their extensibility kinds are not specified. Per this specification, the kind EXTENSIBLE will be inferred by default but could be overridden by implementations. In order to be clear and avoid potential interoperability problems, these types should explicitly specify the extensibility kind EXTENSIBLE, just as all other policies do.
    Resolution:
    Add the built-in annotation @Extensibility(EXTENSIBLE_EXTENSIBILITY) to the definitions of DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy in the IDL file.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add the built-in annotation @Extensibility(EXTENSIBLE_EXTENSIBILITY)
    to the definitions of DataRepresentationQosPolicy and
    TypeConsistencyEnforcementQosPolicy in the IDL file.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unclear member names when programming language doesn’t support typedef

  • Key: DDSXTY-11
  • Legacy Issue Number: 15691
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Summary:
    In the IDL definitions for the specification section Representing Types with TypeObject, some members of type MemberId are named simply member, and some members of type TypeId are named simply type. The fact that the integral types of these members represent IDs is clear to readers of the IDL or to readers of generated code in languages that support typedef (such as C), because the type name is explicit. However, in Java and other programming languages that do not support typedef, the types of these members degrades to simply int (or another built-in integral type). This type obscures the meanings of the members.
    Resolution:
    Name the members in question more explicitly: member_id and type_id.
    Revised Text:
    Rename the following type members in the IDL file:
    • AnnotationUsageMember::member ? AnnotationUsageMember::member_id
    • AnnotationUsage::type ? AnnotationUsage::type_id
    • TypeProperty::id ? TypeProperty::type_id
    • MemberProperty::id ? MemberProperty::member_id
    • MemberProperty::type ? MemberProperty::type_id

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Name the members in question more explicitly: member_id and type_id.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of built-in IDL annotation @Shared is missing

  • Key: DDSXTY-10
  • Legacy Issue Number: 15690
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The Type System defines a type member attribute shared, which indicates that a member should be stored by reference instead of by value to enable the use of external stores—for example, for large data members. This attribute appears in the TypeObject IDL definitions as a built-in annotation @Shared. However, this built-in annotation is never formally defined. (Possibly, it was deleted accidentally in a previous revision of the specification document.)
    Resolution:
    Add a section defining this built-in annotation to section 7.3.1.3, Built-in Annotations.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add a section defining this built-in annotation to section 7.3.1.3, Built-in Annotations.
    Issue 15707, Improve support for shared data, needs to update the description of this new section. The FTF should not create the section in this issue only to modify it in that one. Rather, we should merge this issue with that one and make the entire change in one place.
    Revised Text:
    See issue 15707.
    Disposition: Merged with issue 15707

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of type “Parameters” inadvertently missing

  • Key: DDSXTY-12
  • Legacy Issue Number: 15692
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL definition of the type AnnotationDescriptor from the section Representing Types with TypeObject depends on a typedef “Parameters,” which is an alias to a string-to-string map. This type definition was present in earlier revisions of the IDL file but was inadvertently deleted in the adopted revision.
    Resolution:
    Restore the missing type definition.
    Revised Text:
    Add the following definition immediately before AnnotationDescriptor in the IDL file:
    typedef map<ObjectName, ObjectName> Parameters;

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Restore the missing type definition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT