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

Open Issues

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

Issues Descriptions

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, 24 Apr 2017 16:16 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 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, 24 Apr 2017 12:24 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: Fri, 7 Apr 2017 00:44 GMT