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: 7
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

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

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

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

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

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