DDS-XTypes 1.3 RTF Avatar
  1. OMG Issue

DDSXTY13 — Further corrections

  • Key: DDSXTY13-12
  • 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