1. OMG Mailing List
  2. DDS XTypes 1.4 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: dds-xtypes-rtf
  • Issues Count: 46

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSXTY14-4 Wrong name for DataRepresentationQosPolicy field DDS-XTypes 1.3b1 open
DDSXTY14-2 Specify more clearly which types have a name and how it is constructed DDS-XTypes 1.3b1 open
DDSXTY14-1 Add Unions to types supported in Queries and Filters DDS-XTypes 1.3b1 open
DDSXTY13-10 Union discriminator value without associated member DDS-XTypes 1.2b1 open
DDSXTY13-6 Restrictions on MAP key element type should include ENUM DDS-XTypes 1.2b1 open
DDSXTY13-31 Redefinition of the LC=6 and LC=7 DDS-XTypes 1.2 open
DDSXTY13-28 Computation of KeyHash (7.6.7 Interoperability of Keyed Topics) needs additional detail DDS-XTypes 1.2 open
DDSXTY13-27 Clarify valid ranges of memberIDs DDS-XTypes 1.2 open
DDSXTY13-13 Union default values (Table 9) DDS-XTypes 1.2b1 open
DDSXTY13-9 Explicitly define the values for ReliabilityQosPolicyKind DDS-XTypes 1.2 open
DDSXTY13-8 The definition of ReliabilityQosPolicyKind in Annex D is inconsistent with RTPS DDS-XTypes 1.2 open
DDSXTY13-23 Inheritance rules not sufficient regarding keys and memberID assignment DDS-XTypes 1.2 open
DDSXTY13-20 Reseting the alignment after Encapsulation Header DDS-XTypes 1.2 open
DDSXTY13-42 Compatibility of Enum should be allowed even if there is just one common literal DDS-XTypes 1.2 open
DDSXTY13-36 Remove Endianness bit from DHEADER DDS-XTypes 1.2 open
DDSXTY13-32 Ambiguity in Table 9 and Obsolete language in section 7.3.1.2.1.10 DDS-XTypes 1.2 open
DDSXTY13-43 Organization of section 7.2.2.4.4 is confusing DDS-XTypes 1.2 open
DDSXTY13-26 Setting of @default with @optional members DDS-XTypes 1.2 open
DDSXTY13-16 Provide a more efficient serialization for short strings and sequences DDS-XTypes 1.2 open
DDSXTY13-15 Be explicit about which Types can be used for DDS Topics DDS-XTypes 1.2 open
DDSXTY13-12 Further corrections DDS-XTypes 1.2b1 open
DDSXTY13-21 Type compatibility when members types define keys DDS-XTypes 1.2 open
DDSXTY13-17 Annotation for denoting topic types DDS-XTypes 1.2b1 open
DDSXTY13-41 Rules for type compatibility are incomplete DDS-XTypes 1.2 open
DDSXTY13-73 Correct listed inconsistencies & missing items DDS-XTypes 1.2 open
DDSXTY13-64 Type compatibility rules for structs with keys DDS-XTypes 1.2 open
DDSXTY13-52 Duplication of sections 7.3.1.2.3 and 7.3.1.2.6 DDS-XTypes 1.2 open
DDSXTY13-49 Add a Need @data_representation annotation DDS-XTypes 1.2 open
DDSXTY13-4 XSD for XML type representation should not specify default values for attributes representing annotations DDS-XTypes 1.2 open
DDSXTY13-5 Typographical corrections and minor rewordings DDS-XTypes 1.2b1 open
DDSXTY13-29 Endianess bit in DHEADER causes innefficiencies DDS-XTypes 1.2 open
DDSXTY13-24 Incomplete application of issue DDSXTY12-18 resolution DDS-XTypes 1.2 open
DDSXTY13-11 DynamicType / DynamicTypeBuilder multiplicity of members DDS-XTypes 1.2b1 open
DDSXTY13-22 Description of KeyHash computation needs update to CDR version 2 DDS-XTypes 1.2 open
DDSXTY13-19 Representation of Built-in Annotations in Dynamic Types DDS-XTypes 1.2 open
DDSXTY13-18 Clarify which of the options bits are set to indicate padding bytes DDS-XTypes 1.2 open
DDSXTY13-40 Restructure Section 7.2 "Type System" to include the annotation semantics & align with IDL 4.2 DDS-XTypes 1.2 open
DDSXTY13-60 Update Normative references to latest versions of IDL and DDS DDS-XTypes 1.2 open
DDSXTY13-46 Need @data_representation annotation and clean terminology in 7.4.x DDS-XTypes 1.2 open
DDSXTY13-2 Algorithm to compute autoid is missing from the specification DDS-XTypes 1.2 open
DDSXTY13-1 Inconsistencies and missing items DDS-XTypes 1.1 open
DDSXTY13-7 Add support for signed and unsigned 8-bit integers DDS-XTypes 1.2 open
DDSXTY13-81 Correct XSD issues identified during AB review DDS-XTypes 1.2 open
DDSXTY13-83 Missing parameter in Annex C operation DynamicDataFactory::create_data DDS-XTypes 1.2 open
DDSXTY13-80 Clarify whether the algorithm to compute KeyHash is specific to XTYPES DDS-XTypes 1.2 open
DDSXTY13-79 Need to add an ignore_enum_literal_names in TypeConsistencyEnforcement QosPolicy DDS-XTypes 1.2 open

Issues Descriptions

Wrong name for DataRepresentationQosPolicy field

  • Key: DDSXTY14-4
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 7.6.3.1.3 'DataRepresentationQosPolicy: Platform-Specific API' states:

    The topic, publication, and subscription built-in topic data types shall each indicate the data representation of the associated entity with a new member:

    @id(0x0073) DDS::DataRepresentationQosPolicy representation;

    This does not follow the naming conventions for field names. Instead it should have said that the new member should be:
    @id(0x0073) DDS::DataRepresentationQosPolicy data_representation;

    Likewise in Annex D the declarations of structures TopicBuiltinTopicData, TopicQos, PublicationBuiltinTopicData, DataWriterQos, SubscriptionBuiltinTopicData, and DataReaderQos all have the member:

    @id(0x0073) DDS::DataRepresentationQosPolicy representation;
    

    This should be changed so the member is:

    @id(0x0073) DDS::DataRepresentationQosPolicy data_representation;
    
  • Reported: DDS-XTypes 1.3b1 — Thu, 15 Aug 2019 00:46 GMT
  • Updated: Thu, 15 Aug 2019 00:46 GMT

Specify more clearly which types have a name and how it is constructed

  • Key: DDSXTY14-2
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 7.2.2.1 'Namespaces' states:

    Modules are namespaces whose contained named elements are types. The concatenation of module names with the name of a type inside of those modules is referred to as the type’s “fully qualified name.”

    This is not enough to fully determine the fully qualified name. How is the "concatenation" done? What character is used to separate the successive module names?

    For example what should be the fully-qualified name of the type described in in the following IDL?

    module A {
    module B {
      struct Foo {
        ...
      };
    };
    };
    

    Assuming "::" is used to separate namespaces it would be "A::B::Foo"

    The issue of type names is a bit broader. Currently it is not so clear that every type has a name. Is that really so? What about anonymous types defined within a structure?

    The definition of MemberDescriptor (7.5.2.7) which is used to describe members of a Structure seems to imply every type must have a name. This is because each MemberDescriptor has an associated DynamicType (7.5.2.7.10 'Property: type') which according to 7.5.2.7.10 it cannot be null. And the DynamicType::get_name() should return the name of the type.

    On the other hand Figure 5 seems to indicate only Modules and ConstructedTypes (according to Fig 5 these are: Alias, AggregateTypes, EnumeratedType, Collection) have a "ScopedIdentifier" which is their name.

    This would mean that PrimitiveTypes, StringType do not have a ScopeIdentifyer/name. This seems problematic,

    • PrimitiveTypes do seem to have a name as it is used when defining struct members of that type.
    • CollectionTypes do not seem to have a name.

    However nothing really says that typenames should be globally unique. They only need to be unique within a compilation unit...

  • Reported: DDS-XTypes 1.3b1 — Sun, 4 Aug 2019 20:29 GMT
  • Updated: Mon, 5 Aug 2019 10:06 GMT

Add Unions to types supported in Queries and Filters

  • Key: DDSXTY14-1
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    "Member Names" (7.6.7.1) is missing support for Unions. Union members can be accessed by name as long as a reserved name is specified for the discriminator. A valid filter expression needs to check the discriminator before accessing another member name (for example u.disc = 3 AND u.val < 100), however the implementation doesn't need to check for this. If evaluating a filter expression causes access to an inactive element of a union, the result is undefined.

  • Reported: DDS-XTypes 1.3b1 — Mon, 22 Jul 2019 15:36 GMT
  • Updated: Mon, 22 Jul 2019 15:36 GMT

Union discriminator value without associated member

  • Status: open  
  • Source: Airbus Group ( Oliver 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Restrictions on MAP key element type should include ENUM

  • Key: DDSXTY13-6
  • Status: open  
  • Source: Airbus Group ( Oliver 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Redefinition of the LC=6 and LC=7

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Clarify valid ranges of memberIDs

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Union default values (Table 9)

  • Status: open  
  • Source: OCI ( 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Explicitly define the values for ReliabilityQosPolicyKind

  • Key: DDSXTY13-9
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

The definition of ReliabilityQosPolicyKind in Annex D is inconsistent with RTPS

  • Key: DDSXTY13-8
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Inheritance rules not sufficient regarding keys and memberID assignment

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Reseting the alignment after Encapsulation Header

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Remove Endianness bit from DHEADER

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Ambiguity in Table 9 and Obsolete language in section 7.3.1.2.1.10

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Organization of section 7.2.2.4.4 is confusing

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Setting of @default with @optional members

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Provide a more efficient serialization for short strings and sequences

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Be explicit about which Types can be used for DDS Topics

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Further corrections

  • Status: open  
  • Source: Airbus Group ( Oliver 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Type compatibility when members types define keys

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Annotation for denoting topic types

  • Status: open  
  • Source: Airbus Group ( Oliver 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Rules for type compatibility are incomplete

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Correct listed inconsistencies & missing items

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    This issue was incorrectly entered. It was an attempt to create a proposal for DDSXTY13-1 which ended up creating a new issue.

  • Reported: DDS-XTypes 1.2 — Thu, 7 Feb 2019 22:02 GMT
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Type compatibility rules for structs with keys

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Duplication of sections 7.3.1.2.3 and 7.3.1.2.6

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Add a Need @data_representation annotation

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

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

  • Key: DDSXTY13-4
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT
  • Attachments:

Typographical corrections and minor rewordings

  • Key: DDSXTY13-5
  • Status: open  
  • Source: Airbus Group ( Oliver 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Endianess bit in DHEADER causes innefficiencies

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Incomplete application of issue DDSXTY12-18 resolution

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

DynamicType / DynamicTypeBuilder multiplicity of members

  • Status: open  
  • Source: Airbus Group ( Oliver 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Description of KeyHash computation needs update to CDR version 2

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Representation of Built-in Annotations in Dynamic Types

  • Status: open  
  • Source: MilSOFT ( 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

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

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Update Normative references to latest versions of IDL and DDS

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 3. 'Normative References' points to older versions of IDL ad DDS. Update those references the latest version.

  • Reported: DDS-XTypes 1.2 — Sun, 2 Dec 2018 05:23 GMT
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Need @data_representation annotation and clean terminology in 7.4.x

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Algorithm to compute autoid is missing from the specification

  • Key: DDSXTY13-2
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Inconsistencies and missing items

  • Key: DDSXTY13-1
  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Add support for signed and unsigned 8-bit integers


Correct XSD issues identified during AB review

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • 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
  • Updated: Mon, 1 Apr 2019 17:40 GMT

Missing parameter in Annex C operation DynamicDataFactory::create_data

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The IDL declaration of interface DynamicDataFactory in Annex C, declares the operation with no arguments.

    However according to section 7.5.2.10 'DynamicDataFactory' the operation takes a parameter of type DynamicType. Therefore the correct IDL declaration should have been:

            DynamicData create_data(in DynamicType);
    
  • Reported: DDS-XTypes 1.2 — Thu, 14 Mar 2019 04:11 GMT
  • Updated: Thu, 14 Mar 2019 04:13 GMT

Clarify whether the algorithm to compute KeyHash is specific to XTYPES

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In 7.6.8 'Interoperability of Keyed Topics' it states:

    As described in [RTPS] Clause 9.6.3.8, “KeyHash (PID_KEY_HASH)”, the key hash for a given object of a keyed type is obtained by first serializing the values of the key members in their declaration order. The algorithm described in that clause shall be amended as described below.

    It is not clear whether the intent is that this modification impacts only implementors of the DDS-XTYPES or whether it is intended as a change in RTPS (which would require an issue filed on the DDSI-RTPS specification).

  • Reported: DDS-XTypes 1.2 — Fri, 8 Mar 2019 04:13 GMT
  • Updated: Fri, 8 Mar 2019 04:13 GMT

Need to add an ignore_enum_literal_names in TypeConsistencyEnforcement QosPolicy

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The type assignability rules for Enumerated Types require knowledge of whether the literal names should be considered for assignability.

    Right now this can only be configured when the type is declared using the @ignore_literal_names annotation. However in some cases it may be necessary to change this behavior at run-time for a particular DataReader.

    To support this use-case it would be helpful to add a ignore_enum_literal_names field to the TypeConsistencyEnforcement QosPolicy

  • Reported: DDS-XTypes 1.2 — Sat, 2 Mar 2019 00:27 GMT
  • Updated: Sat, 2 Mar 2019 00:27 GMT