Issues for DDS XTypes 1.2 Revision Task Force

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 18144: Key order should be defined using the @Key annotation (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Angelo Corsaro, PhD., angelo.corsaro(at)adlinktech.com)
Nature: Enhancement
Severity: Significant
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.

Resolution: 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.
Revised Text:
Actions taken:
October 8, 2012: received issue
April 6, 2017: Closed; No Change
June 22, 2017: closed issue

Issue 18145: A @Version annotation shall be added (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Angelo Corsaro, PhD., angelo.corsaro(at)adlinktech.com)
Nature: Enhancement
Severity: Critical
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;  };

Resolution: 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
Revised Text: At the end of section 7.3.1.3, add sub-section 7.3.1.3.11 with the content below: 7.3.1.3.11 Version Tag The Type System defined in this specification supports type evolution where the rules to determine whether two versions of the type are compatible only depends on the structure of the type and not on the type names or any version tags. These rules are defined in clause 7.2.4 (Type Compatibility: ?is-assignable-from? relationship). However, to facilitate system integration, and to detect and troubleshoot configuration problems it may be useful to have additional information that informs whether type differences are the result of an intentional type evolution or represent a potential issue. Furthermore, it may be beneficial to have an indication of when the type version was defined. These capabilities could be added by application developers or vendors using custom annotations. But this approach would result in the annotation name and usage being completely different for different applications and middleware implementations, thus missing the benefit of leveraging a common "established best practice." The "Version" annotation addresses this need providing a common syntax and practice. Version objects associated with a constructed type declaration shall be indicated using the following annotation: @Annotation local interface Version { attribute string<32> tag default ""; attribute string<32> date_time default ""; }; This annotation may be applied to the definitions of aggregated types. It shall be considered an error for it to be applied to the same type multiple times. The presence of the "Version" annotation does not impact the compatibility of types. However, when the annotation is present it indicates intent by the application developer to explicitly and uniquely name a specific version of the data type. The implied semantic is that types annotated with the same version tag should be identical. The Version date_time is intended to encode the date when that version was created. Tools may use the value of the "Version" annotation to alert of discrepancies where the tag value is the same but the type definition or the date_time are not identical. Tools may also use the annotation tag as a way to help users identify or select versions of a data type and they can use the date_time to deduce a chronology on when the versions were created. There is no specific format associated with the tag attribute. Vendors and application developers may use their own conventions. For example, some applications may choose a numeric convention (e.g. dot-separated major, minor, and revision numbers ) and others may choose simple textual tags (e.g. the release name when available). The date_time field shall use a subset of the formats defined in [ ISO 8601:2004 ] as defined in [ IETF RFC 3339 ]. Below are some example date_time strings that comply with this syntax: The date_time "2016-11-05T08:15:30-08:00" corresponds to November 5, 2016, 8:15:30 am, Pacific Standard Time. The date_time "2016-11-05T16:15:30Z " corresponds to the same instant, using the UTC designator "Z". In section 3 (Normative References) add the following references: *[ ISO-8601:2004 ] ISO 8601:2004 1988 (E), "Data elements and interchange formats - Information interchange - Representation of dates and times". *[ IETF RFC 3339 ] IETF RFC 3339, "Date and Time on the Internet: Timestamps". [1]https://tools.ietf.org/html/rfc3339. ---------------------------------------------------------------------------------------- [1] https://tools.ietf.org/html/rfc3339
Actions taken:
October 8, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18146: Improving Extensible Types (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Angelo Corsaro, PhD., angelo.corsaro(at)adlinktech.com)
Nature: Enhancement
Severity: Critical
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.

Resolution: |
Revised Text: In Section 3 Normative References add the following reference: *[IEEE-754] IEEE Standard for Binary Floating-Point Arithmetic, 754-2008 - IEEE Standard for Floating-Point Arithmetic In Section 7.2.3 Type Extensibility and Mutability replace (on top of the changes introduced by [1]DDSXTY12-122): * final with FINAL * append with APPENDABLE * mutable with MUTABLE Also, add at the end of the second bullet point (which begins with "A type may be APPENDABLE") the following sentence: Note that this was called EXTENSIBLE in xtypes version 1.1 and prior. Rename all references to "append" extensibility to "appendable" extensibility throughout the document. Rename Section "7.4.1 Extended CDR Data Representation" to "7.4.1 Extended CDR Data Representation (encoding version 1) and edit the text as follows:" This specification defines an extension s of the OMG CDR representation [CDR] that is able to accommodate both optional members and appendable/mutable types. These extensions result in two encoding formats: PLAIN_CDR and PL_CDR. : The Both specification encoding formats leverage s the OMG CDR representation for all primitive types and non-mutable constructed types where the (traditional) CDR representation is well defined . : *The PLAIN_CDR specification introduces extensions to CDR in order to handle optional members, bitmasks sets, and maps. *PL_CDR The specification leverages the RTPS Parameter List representation [RTPS] to handle type mutable extensibility types. Rename Section "7.4.1.1 Use of the (Traditional) OMG CDR" to "7.4.1.1 PLAIN_CDR Representation" and edit it as follows: *The traditional PLAIN_ CDR representation shall be used for final and extensibleappend types, including (trivially) primitive types. It shall also be used for all string, sequence, and map types. Aggregated types declared as mutable shall use the Parameterized CDR PL_CDR representation described in Section 7.4.1.2. *The PLAIN_ CDR representation is based on the traditional CDR representation format [CDR] with the minimal extensions described below needed to handle the new types and concepts introduced by this specification. *... Add a subsection of 7.4.1.1 named "7.4.1.1.1 Primitive types" with the following content: The PLAIN_CDR representation for primitive types shall be the same as in ?traditional? CDR [CDR]. Specifically: *The serialized data shall be encoded at an offset that aligned to the size of the primitive type. *An endianness byte swap shall be performed in case the native system endianess is different from the one currently configured in the XCDR stream (XCDR.cendien). The following table summarizes the serialization of various primitive types. Table 29 Serialization of primitive types in version 1 encoding Primitive Type Encoded Size Alignment (version 1) Byte representation Byte 1 1 The byte value Boolean 1 1 0 for false, 1 for true Char8 1 1 The character value encoded as described in 7.2.2.2.1.2 Char16 2 2 The character value encoded as described in 7.2.2.2.1.2 Int16/UInt16 2 2 The integer value using two?s complement notation Int32/UInt32 4 4 The integer value using two?s complement notation Int64/UInt64 8 8 The integer value using two?s complement notation Float32 4 4 IEEE standard for normalized single-precision floating-point numbers [IEEE-748] Float64 8 8 IEEE standard for normalized double-precision floating-point numbers [IEEE-748] Float128 16 8 IEEE standard for normalized quadruple-precision floating-point numbers [IEEE-748] Add new subsection of 7.4 Data Representation named "7.4.2 Extended CDR Data Representation (encoding version 2)" before the XML Data Representation Section with the following content This specification defines three encoding formats used with encoding version 2: PLAIN_CDR2, DELIMITED_CDR, and PL_CDR2. The three encoding formats leverage the PLAIN_CDR representation. They enhance the encodings used in version 1 to improve type assignability and reduce the size of serialized data. *PLAIN_CDR2 shall be used for all primitive, strings, and enumerated types. It is also used for any type with extensibility kind FINAL. The encoding is similar to PLAIN_CDR except that INT64, UINT64, FLOAT64, and FLOAT128 are serialized into the CDR buffer at offsets that are aligned to 4 rather than 8 as was the case in PLAIN_CDR. *DELIMITED_CDR shall be used for types with extensibility kind APPENDABLE. It serializes a UINT32 delimiter header (DHEADER) before serializing the object using PLAIN_CDR2. The delimiter encodes the endianess and the length of the serialized object that follows. *PL_CDR2 shall be used for aggregated types with extensibility kind MUTABLE. Similar to DELIMITED_CDR it also serializes a DHEADER before serializing the object. In addition it serializes a member header (EMHEADER) ahead each serialized member. The member header encodes the member ID, the must-understand flag, and length of the serialized member that follows. Add another Subsection of 7.4 "Data Representation" before "XML Data Representation" right after the new "Extended CDR Data Representation (encoding version 2) section" named "7.4.3 Extended CDR encoding virtual machine" with the following content: The encoding formats are specified using a virtual machine that acts on a XCDR stream object. The XCDR stream holds the bytes resulting from the incremental serialization of data objects into the stream. The XCDR stream model consists of: *A linear byte buffer where the serialized objects are placed *A set of internal state variables that may affect the serialization of future objects serialized into the stream. See Table 3. *A set of operations on the stream that modify the state variables. See Table 35. *A ?stream insertion? operation that serializes objects onto the stream with a format that depends on the object type, its composition, and the value of the state variables. The append operation is represented using the operator symbol ?<<?. See Table 35. 7.4.3.1 Encoding version and format The encoding format is determined by the encoding version and the extensibility kind of the object being serialized. Table 33 specifies the format that shall be used in each case. Table 33 - Serialization format to use. Extensibility Kind Encoding Version Encoding format on the wire FINAL 1 PLAIN_CDR FINAL 2 PLAIN_CDR2 APPEND 1 PLAIN_CDR APPEND 2 DELIMITED_CDR MUTABLE 1 PL_CDR MUTABLE 2 PL_CDR2 7.4.3.2 XCDR Stream State 7.4.3.2.1 XCDR stream state variables The state of the XCDR stream is described by the value of the variables (the XCDR state variables) defined in Table 34. Table 34 - State variables and constants in the XCDR stream model +-----------------------+------------------------------------------------------------+ | XCDR state variable | meaning | +-----------------------+------------------------------------------------------------+ | NENDIAN | Constant that represents the native endianness used by the | | | system. It is dependent on the processor architecture, | | | compiler, and operating system. | | | | | | There are two possible values: LITTLE_ENDIAN and | | | BIG_ENDIAN | +-----------------------+------------------------------------------------------------+ | cendian | Choice variable representing the current endianness. This | | | is the endiannes that will be used to serialize subsequent | | | objects into the stream. It affects integer types, | | | floating-point types, enumerated types, and the Char16 | | | type. | +-----------------------+------------------------------------------------------------+ | offset | Integer variable representing the offset into the byte | | | stream where the next serialized byte will be placed. | | | | | | XCDR.offset is computed relative to the beginning of the | | | stream so that XCDR.offset counts the number of bytes | | | currently serialized into the stream. | | | | | | Each byte serialized into the stream causes XCDR.offset | | | to be incremented. | +-----------------------+------------------------------------------------------------+ | origin | Integer state variable representing the offset into the | | | stream used as the ?logical beginning of the stream? for | | | alignment operations. | | | | | | Each Type ?T? has a default alignment (T.dalignment). | | | This is the alignment used by default when an object of | | | that type is serialized into a stream. | | | | | | An object O of type T shall be serialized at an offset that| | | verifies: | | | | | | ((XCDR.offset - XCDR.origin) % T.dalignment) == 0 | | | | | | If the current XCDR.offset does not satisfy the above | | | condition, the serialization shall insert the minimum | | | ?padding bytes? needed to advance XCDR.offset so that the | | | condition is met. | +-----------------------+------------------------------------------------------------+ | eversion | Octet state variable used to identify the version of the | | | encoding rules used to serialize the stream. | | | | | | The pre-defined values are: | | | {0x00} -- VERSION_NONE | | | {0x01} -- VERSION1 | | | {0x02} -- VERSION2 | +-----------------------+------------------------------------------------------------+ | maxalign | Integer state variable representing the maximum value for | | | the alignment that will be used for future objects | | | serialized into the stream. This value overrides the | | | required alignment for the object being serialized, so the | | | alignment condition for any object O of type O.type | | | becomes: | | | | | | ((XCDR.offset - XCDR.origin)% MALIGN(O))== 0 | | | | | | Where | | | | | | MALIGN(O) = MIN(O.type.alignment, XCDR.maxalign) | | | | | | This value is automatically set from the XCDR.eversion. | | | | | | XCDR.maxalign == MAXALIGN( XCDR.eversion ) | +-----------------------+------------------------------------------------------------+ 7.4.3.2.2 Operations that change the XCDR stream state The XCDR stream state is modified as a result of the serialization of data objects into the stream. It can also be modified as a result of performing the operations shown in Table 35. Table 35 Stream operations in the XCDR stream model +------------------------------+-------------------------------------------------------+ | XCDR stream operation | meaning | +------------------------------+-------------------------------------------------------+ | INIT(V1=<nv1>, V2=<nv2>,...) | Initializes (constructs) the XCDR stream and sets the | | | state variables V1, V2, ... as specified. | | | | | | The notation <?> indicates that the value can be | | | chosen by the implementation | +------------------------------+-------------------------------------------------------+ | PUSH(VARIABLE=<newvalue>) | Pushes the specified XCDR stream variable VARIABLE | | | into the stack and sets the current value to | | | <newvalue> | | | | | | The notation <?> indicates that the new value can be | | | chosen by the implementation. | | | | | | This action is reverted by the POP() operation. | +------------------------------+-------------------------------------------------------+ | PUSH(V1=<nv1>,V2=<nv2>,...) | A shortcut for calling PUSH() multiple times with the | | | listed variables and new values. | +------------------------------+-------------------------------------------------------+ | POP(VARIABLE) | Replaces the XCDR stream variable VARIABLE with the | | | value for that variable that was pushed on the last | | | PUSH() operation, removing it from the stack. | +------------------------------+-------------------------------------------------------+ | MAXALIGN(<eversion>) | This operation returns the maximum alignment used for | | | a given version of the encoding: | | | | | | MAXALIGN( VERSION2) = 4 | | | MAXALIGN( VERSION1) = 8 | | | MAXALIGN( VERSION_NONE) = 8 | +------------------------------+-------------------------------------------------------+ | ALIGN(N) | This operation is used to advance the XCDR stream to | | | achieve a desired alignment of the XCDR.offset. | | | | | | Advancing the XCDR.offset is done by inserting | | | ?padding bytes? into the stream. The value of the | | | padded bytes is left unspecified. | | | | | | The actual number of bytes advanced depends not only | | | on ?N? but also on the value of the XCDR.maxalign. | | | Specifically the stream is aligned to neededalign: | | | neededalign = MIN(N, XCDR.maxalign) | | | | | | After the operation is performed the following | | | condition shall be true: | | | | | | (XCDR.offset - XCDR.origin) % neededalign == 0 | +------------------------------+-------------------------------------------------------+ | XCDR << { O : T } | The ?append? stream operation. | | | Serializes (using the Extended CDR representation) an | | | object ?O? of type ?T? onto the XCDR stream starting | | | at offset XCDR.offset. | +------------------------------+-------------------------------------------------------+ 7.4.3.2.3 XCDR Stream Initialization The XCDR stream shall be initialized with an empty buffer. The endianness shall be set as desired by the implementation, although a common setting for best performance is the native system endianness (NENDIAN). The encoding version (eversion) shall be set as configured on the DataWriter. In this version of the DDS-XTypes specification it may be set to 1 or 2. The first 2 octets in the XCDR stream shall the Encapsulation Header (ENC_HEADER) indicating the endianness, encoding version, and encoding algorithm of the top-level type. See Table XX. This is the type associated with the DataWriter. 7.4.3.3 Type and Byte transformations The operation of the serialization virtual machine uses a set of helper type and byte-buffer transformations. The type transformations transform a type into another type, typically modifying its extensibility kind. The byte-buffer transformations perform byte swaps in arrays of bytes or allow reinterpreting an object of a primitive type as an array of bytes. These transformations are used to decompose the serialization of one type as a set of serializations of other types which have already been described. Table 36 defines the type and byte transformations. Table 36 Type and Byte transformations used in the serialization virtual machine +-------------------------------+------------------------------------------------------+ | Type or Object transformation | meaning | +-------------------------------+------------------------------------------------------+ | AsFinal(T) for any type T | This transformation only affects Aggregated types. | | | For other types AsFinal(T) returns T. | | | | | | For the affected types AsFinal(T) is a new type | | | which is declared the same as T except that its | | | extensibility kind is FINAL. | +-------------------------------+------------------------------------------------------+ | AsNested(T) for any type T | This transformation treats the type as a Nested type | | | for serialization purposes. | +-------------------------------+------------------------------------------------------+ | AsBytes(O) for any object O | This transformation reinterprets the primitive | | of a PRIMITIVE_TYPE | object as an array of bytes. | | | The resulting bytes are ordered as they appear in | | | the processor memory according to the native | | | Endianness (NENDIAN) used by the system. | +-------------------------------+------------------------------------------------------+ | ESWAP(B, <doit>) | Conditionally swaps the bytes on the input stream B | | where B is a stream of 1, 2, | based on whether the current XCDR endianness | | 4, or 8 bytes | (XCDR.cendian) matches the native Endianess | | | (NENDIAN). | | | | | | This operation returns the same input stream if the | | | input is a single byte or if XCDR.cendian == NENDIAN.| | | | | | Otherwise the operation produces a new stream of | | | bytes with the same length as the input performing | | | an (endianness) byte swapping according to the | | | length of the input stream: | | | For length 2: { B[1], B[0] } | | | For length 4: { B[3], B[2], B[1], B[0] } | | | For length 8: { B[7], B[6], B[5], B[4], B[3], | | | B[2], B[1], B[0] } | +-------------------------------+------------------------------------------------------+ 7.4.3.4 Functions related to data types and objects The operation of the serialization virtual machine uses a set of helper functions that return bytes or data to append to the XCDR stream. The notation and meaning is defined in Table 37. Table 37 Functions operating on objects and types +-------------------------------+------------------------------------------------------+ | function | meaning | +-------------------------------+------------------------------------------------------+ | ENC_HEADER( | ENC_HEADER is an array of 2 octets used to identify | | <E>, <eversion>, T) | the type of encoding (serialization), version of the | | for any type ?T? | encoding (<eversion>) and the endianness used by the | | | stream (<E>): | |
Actions taken:
October 8, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18292: Proposed type-naming scheme is far from Robust (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Revision
Severity: Significant
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.

Resolution: 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 [1]DDSXTY12-100 modified the TypeObject and now anonymous collection types no longer need a name. The issue is merged with [2]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. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY12-100 [2] http://issues.omg.org/browse/DDSXTY12-100
Revised Text:
Actions taken:
December 12, 2012: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 18293: Applicable key types not clearly specified (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text: In section 7.2.2.3.5.6 (Key Members) make the following edits After the second paragraph which starts with "Key members shall never be optional..." add the text: A type's key can only include members of the following types: primitive, aggregation, enumeration, bitset, array, and sequence. Aliases to one of the previous types can also be used as key members. Members of type map cannot be included as part of the key. Break the first 3 sentences of the third paragraphs into 3 separate paragraphs. Each starting with: Which members may together ... In a structure type, the key ... In a union type, only the discriminator ... After the sentence that starts with "In a union type, only the discriminator..." and before the sentence that starts with "In the event that the type K of a key member ..." insert the following text: The union discriminator is marked as a key by annotating the discriminator itself with the @Key annotation as shown in the example below: enum CommandKind { START, STOP, GO_LEFT, GO_RIGHT }; union MyCommand switch (@Key CommandKind) { case START: float delay; /* delay until start in seconds */ case STOP: float distance; /* distance to stop in meters */ case GO_LEFT: case GO_RIGHT: float angle; /* Angle to change direction in radians */ }; If a member of type array or sequence is marked as a key member of an aggregated type T, all the elements in the array or sequence shall be considered part of the key of T. In the case of a sequence, the length of the sequence is also considered as part of the key ahead of the sequence elements. Separate the sentence that starts with "In the event that the type K of a key member of a given type T itself defines key members, ..." into its own paragraph Separate the sentence that starts with "For example, suppose the key of a medical record.." into its own paragraph.
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18294: Typo in opening sentence of section: Missing noun and verb (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Minor
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.

Resolution: Corrected sentence: System developers frequently require the ability to inject their own text into the code produced by a Type Representation compiler.
Revised Text:
Actions taken:
December 12, 2012: received issue
April 25, 2014: closed issue

Issue 18295: Shareable members underspecified (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Minor
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?

Resolution: Added clarification for Shareable members Updated the description in section 7.3.1.3.4.
Revised Text: A member declared as shareable within an aggregated type indicates that it is desirable for the implementation to store the member in storage external to the enclosing aggregate-type object. A suitable implementation in common programming languages may be a pointer to the member. Unless also annotated as Optional, shareable members shall always be present and therefore the pointer (if that is the representation used) to non-optional shareable members cannot be NULL. Non-optional shareable members can be annotated as Key. The purpose of shareable data (annotated as @shared) is not to facilitate graph modeling or graph (de-) serialization. If a conforming implementation encounters a graph (case #2 and #3 below), it is not required to maintain the graph structure through serialization/deserialization. Non-normative note: Three main cases arise when using shareable data (1) tree structure?it is (de-) serializable (2) Diamond case?it is serializable but the bottom-most shared object may be serialized twice turning the graph into a tree. The diamond case is expected to work with some overhead. (3) Cycles?it is not serializable. However a conforming implementation is not required to warn or detect such cases.
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18296: Typo (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Minor
Summary:

Typo: 4rth paragraph: For the saMe of run-time efficiency -> For the saKe of run-time efficiency.....

Resolution: Corrected sentence: For the same sake of run-time efficiency �
Revised Text:
Actions taken:
December 12, 2012: received issue
April 25, 2014: closed issue

Issue 18297: Definition of "strongly assignable" seems to be used inconsitently (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text: Strong Assignability If types T1 and T2 are identical, or alternatively both T1 and T2 are mutable and T1 is-assignable-from T2, then T1 is said to be ?strongly? assignable from T2. Note: Any Any type is also considered (trivially) strongly assignable from itself, regardless of its extensibility kind. Also updated union_type in Table 15 section 7.2.4.5 Aggregation Types. ? When T1 is mutable, 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. ? When T1 is final or extensible, for each member ?m1? in T1, if there is a member m2 in T2 with the same member ID then m1.type is-strongly-assignable-from m2.type.
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18298: member ID algorithm flawed (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Critical
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;  };

Resolution: Add clarifying text to section 7.3.1.3.1 The main part of this issue is addressed in [1]DDSXTY12-18. Therefore, the only thing we need to do here is clarify the member ID rules. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY12-18
Revised Text: In section 7.3.1.3.1 "Member IDs", add the following sentences to the very end of the last paragraph in the section: "It is considered an error if the assignment of member IDs results in two members with the same ID. It is the responsibility of the tool chain that is being used to flag this error at or before compile time or, in the case of DynamicType, during the creation of the DynamicType object. Either way it shall not be possible to define a type with duplicate member IDs."
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18299: Semantics of overriding an attribute not clearly specified (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text:
Actions taken:
December 12, 2012: received issue
April 25, 2014: closed issue

Issue 18300: TypeObject semantics underspecified and inconsistent (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Critical
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.

Resolution: Added clarification for TypeLibrary Added clarification in section 7.3.4.1 that a single TypeLibrary which may recursively contain more TypeLibrary objects
Revised Text: Added clarification in section 7.3.4.1 that a single TypeLibrary which may recursively contain more TypeLibrary objects
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18301: Type system severely underspecified (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Critical
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.

Resolution: TypeId algorithm proposed See RTI's TypeId proposal attached to Issue #7: TypeId calculation errors/corrections. TypeId computation has been unambiguously specified.
Revised Text:
Actions taken:
December 12, 2012: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 18302: XML type description not orthogonal and not consistent (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Significant
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

Resolution: Clarified both xml data representations Resolutions applied: Added the revised text in section 7.4.2.2
Revised Text: Non-normative note: Valid XML data representation can be nearly as compact as the well-formed XML data presentation by using a default namespace. The syntax to select the default namespace is xmlns=?ddstype://www.omg.org/??. No prefix is necessary at every element name as they now default to the default namespace. For really small datatypes (e.g., a 2d point) even the overhead of including the default namespace may be non-trivial. In such cases, well-formed XML data presentation may be preferred.
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18303: C++ shared member representation breaks safety mechanisms of the struct containing it (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Revision
Severity: Significant
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 could reason why to make this one exception for shared pointers, which will make it much harder to predict the struct's behaviour.

Resolution: 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.
Revised Text: In section 3 ?Normative References? add the following bullet point directly after the bullet point for the [C++-MAP] reference: *[DDS-PSM-Cxx] ISO/IEC C++ 2003 Language DDS PSM, Version 1.0 (OMG document formal/2013-11-01) Replace section 7.5.1.2.3 'Shareable Members' with the following: (Note: the included tables shall be created in the same manner as all other tables in the document and not as represented here) 7.5.1.2.3 External Members The storage for a member of an aggregated type may be declared to be external to the storage of the enclosing object of that type. This is desirable, for instance, when the memory for a member may already exist somewhere and an application wants to combine it with other members and publish it as a unit without making additional copies. Another use case is sharing the data associated with the member among members in different objects. The language bindings for C, Traditional C++, C++ for the DDS-PSM-Cxx, and Java are provided in the following subsections. 7.5.1.2.3.1 C This mapping extends the IDL to C language mapping defined in [C-MAP]. External members shall be represented using pointers. Specifically: *String and wide string members are already represented using pointers, so the mappings for these members do not change. The same applies to aliases to string and wide string types. *Other external members are mapped like non-external members except that a member of type X shall instead be mapped as type pointer-to-X. For example, short shall be replaced by short*. The constructor/initializer of the enclosing object shall set the external member pointers to NULL. The destructor of the enclosing object shall delete the objects referenced by non-NULL external member pointers. It is the responsibility of the application to set the external member pointers to NULL before destroying the enclosing object if they do not want to delete specific referenced objects. The copy function of the enclosing object shall do a deep copy of the external members. If the destination external member is NULL it shall be allocated. If the destination external member is not NULL it shall be filled with a copy of the source member (i.e. perform logically a recursive call to copy(destination->pointer-to-X, source->pointer-to-X)). If the (recursive call to the) copy operation of the external member fails, then the copy function of the containing object shall fail as well. This may happen when the destination member is not large enough to hold a copy of the source. There may be an additional copy function that takes in arguments which allow the user to control the behavior of the copy operation. This additional copy function shall allow the user to choose whether a shallow or deep copy is made as well as whether any existing memory pointed by the member is reused, released, or replaced during the copy. In the case that a shallow copy is made and the destination member is NULL then the destination member pointer will be set to the source member pointer. In the case that a deep copy is made and the destination member pointer is NULL, memory for the destination member will be allocated and then copied into. For the behaviors supported by the additional copy function when the destination member is not NULL, see Table XXX. Table XXX. Configurable behaviors of the copy function when destination is not NULL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ | | Action when | | | Copy Type | destination member | Description | | | is not NULL | | +---------------+---------------------+---------+--------------------------------+ | | | Destination will now point to the same | | | | memory address as source. The exisiting | | | Replace | memory pointed to by destination is not | | | | released. The application is responsible | | | | for releasing the replaced memory. | + Shallow Copy +---------------------+------------------------------------------+ | | | Destination will now point to the same | | | Release | memory address as source. The exisiting | | | | memory pointed to by destination is | | | | released before making the assignment. | +---------------+---------------------+------------------------------------------+ | | | (Default) Try to reuse the existing | | | Reuse | memory to copy into. If the existing | | | | member is not large enough, this | | | | operation shall fail | + +---------------------+------------------------------------------+ | | | Replace the destination member. Allocate | | Deep Copy | | new memory to copy into and | | | | replace the existing memory without | | | Replace | releasing it. It is the application?s | | | | responsibility to release the | | | | replaced memory. | + +---------------------+------------------------------------------+ | | Release | Release the existing memory before | | | | allocating new memory to copy into. | +---------------+---------------------+------------------------------------------+ 7.5.1.2.3.1.1 External Optional Members A member that is both external and optional shall be mapped as if it was just external. The difference is that it is valid for the member to be NULL when writing a sample containing this member. If the member is only external but not optional then it is not allowed for the member to be NULL at the time of a write. 7.5.1.2.3.2 Traditional C++ This mapping extends the IDL to C++ language mapping defined in [C++-MAP]. External members shall be represented by any type that behaves similarly to a pointer (e.g. a plain pointer or a _var type). The chosen type must support the concept of being 'unset'. For example, a plain pointer is considered unset if its value is NULL. *In cases where the non-external mapping already uses a a type similar to a pointer, it shall remain unchanged. *In cases where the non-external mapping uses an member of type X, X shall be replaced by pointer-to-X. For example, if plain pointers are used, short shall be replaced by short*. The behavior of the constructor, destructor, and copy functions shall be the same as specified for C. 7.5.1.2.3.2.1 External Optional Members A member that is both external and optional shall be mapped as if it was just external. The difference is that it is valid for the member to be unset when writing a sample containing this member. If the member is only external but not optional then it is not allowed for the member to be unset at the time of a write. 7.5.1.2.3.3 Modern C++ This mapping extends the IDL to C++ language mapping defined in [DDS-PSM-Cxx]. External members shall be represented as an instantiation of a template class external<T>, where T is the type of the external member. This is a ?smart pointer? class that wraps a shared pointer, ptr_ for automatic reference counting and a boolean locked_ that controls the assignment behavior. The destruction of the object referenced by an external member is always managed by the underlying shared pointer. The value of the locked_ attribute dictates whether copying an external member performs a deep copy or shallow copy of the referenced member. It can also be used to prevent sharing of the referenced object. This control is useful in some situations, for example, to prevent sharing a reference to memory that belongs to a DataReader in a DDS application. See sections 7.5.1.2.3.3.4 and 7.5.1.2.3.3.5 for details about the copy constructor and assignment operator. The locked_ attribute is set at the time the external member is constructed and cannot be modified. The locked_ attribute can only be set to TRUE when the shared pointer is set to a non NULL value. The external<T> class shall be generated inside of an appropriate namespace. In the case of the DDS-PSM-Cxx, this namespace is dds::core. namespace dds { namespace core { template <typename T> class external { public: external(); external(T* p, bool locked = false); external(shared_ptr<T> p); external(const external& other); ~external(); external& operator=(const external& other); T& operator*(); const T& operator*() const; T* get(); const T* get() const; shared_ptr<T> get_shared_ptr(); T* operator->(); const T* operator->() const; bool operator==(const external<T>& other) const; bool operator!=(const external<T>& other) const; operator bool() const; bool is_locked() const; void lock(); private: shared_ptr<T> ptr_; bool locked_; }; } } // namespace dds::core 7.5.1.2.3.3.1 Operation: Default Constructor Create an empty external<T> object with an empty ptr_ and locked_ initialized to false. 7.5.1.2.3.3.2 Operation: Constructor from a T* Create an new external<T> object referencing the provided managed object. The attribute locked_ is set to false and ptr_ is initialized with p. Parameter p - The object for _ptr to manage. Parameter locked - Whether or not the constructed external<T> should be locked. This is an optional parameter with a default value of false. 7.5.1.2.3.3.3 Operation: Constructor from a shared pointer to T object Create an new external<T> object that references the same object managed by the specified shared pointer ?p?. The attribute locked_ is set to false and ptr_ is initialized with p. Parameter p - The shared_ptr<T> holding the T* reference that will be shared with the new external<T> object. 7.5.1.2.3.3.4 Operation: Copy Constructor Creates an external object from an existing external object (other). The behavior of this operation depends on the value of the locked_ attribute of the existing external object (other). *If other.is_locked() is false then the new external<T> object shares the reference with other. In other words this operation will not create a T object, instead it will perform a shallow copy of T* pointer. *If other.is_locked() is true then a new T object is created and ptr_ is initialized with a reference to the newly created T object. The contents of newly-allocated object are initialized with a copy from the contents of other. In other words this operation will create a new T object and do a deep copy. Either way, the newly constructed external<T> object will have locked_ set to false. Parameter other - The external object used to initialize the new constructed external<T> object. 7.5.1.2.3.3.5 Operation: Assignment Operator Assigns an external object to another. The behavior of this operation depends on the value of the locked_ attribute both on the source of the copy as well as on the destination. The behavior specified in Table XX below shall be applied when assigning an external<T> object source to another external<T> object destination: Table XX destination destination source source Behavior of assignment operator locked_ ptr_ locked_ ptr_ TRUE <any> <any> <any> Error. Operation cannot be called when destination.is_locked() == TRUE FALSE <any> <any> EMPTY The destination is reset. Result is destination.ptr_ is EMPTY FALSE EMPTY TRUE Not EMPTY Create new object for destination.ptr_ Perform deep copy from source.ptr_ to destination.ptr_ FALSE Not EMPTY TRUE Not EMPTY Reuse existing destination.ptr_ Perform deep copy from source.ptr_ into the existing destination.ptr_ FALSE <any> FALSE Not EMPTY Perform shallow copy. The destination.ptr_ = source.ptr_ Destination will reference same object as source Parameter other - The external object whose contents are assigned to this external object. 7.5.1.2.3.3.6 Operation: Destructor Destroy the external object. If ptr_ is the last reference to the managed object then the managed object will be released, otherwise the reference count will simply be decreased. 7.5.1.2.3.3.7 Operation: operator* (const and non-const versions) Get a reference to the underlying managed object that ptr_ points at. 7.5.1.2.3.3.8 Operation: get (const and non-const versions) Obtains a pointer to the managed object. 7.5.1.2.3.3.9 Operation: get_shared_ptr Obtains a shared pointer to the managed object. 7.5.1.2.3.3.10 Operation: operator-> (const and non-const versions) Allows accessing members of the managed object. 7.5.1.2.3.3.11 Operation: operator== Returns whether two external objects manage the same object or are both empty. 7.5.1.2.3.3.12 Operation: operator!= Returns whether two external objects do not manage the same object. 7.5.1.2.3.3.13 Operation: operator bool Checks if there is a managed object (is not null) or not (is null). 7.5.1.2.3.3.14 Operation: is_locked Indicates whether this object is locked or not. 7.5.1.2.3.3.15 Operation: lock Sets the locked_ attribute to true. This prevents of the external<T> object from modifying the referenced T object. This means that future assignment operations to the external<T> object will fail and any copies from external<T> will be deep copies (i.e. not share a reference to the same underlying T object). 7.5.1.2.3.3.1 External Optional Members A member that is both external and optional shall be mapped as if it was just external. The difference is that it is valid for ptr_ to be empty when writing a sample containing this member. If the member is only external but not optional then it is not allowed for ptr_ to be empty at the time of a write. Put the contents of section 7.5.1.2.3.5 'Java' here unchanged but the the following sentence added as the first sentence of the section: This mapping extends the IDL to Java language mapping defined in [JAVA-MAP].
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18304: Mapping of Map type underspecified for C (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Minor
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

Resolution: Clearly define a C mapping for Map types The C mapping for map types is not well-defined and needs to be added.
Revised Text: In section 7.5.1.3 'Map Types' replace the first two paragraphs: The language binding for map types is defined by an equivalent IDL2 with exceptions for the C++ and Java language where there is native type support for this type. As indicated in Section above, implementers are only required to support keys of integer and string types. If a Type Representation compiler encounters a key type that it does not support, it shall fail with an error. with: The language bindings for C, Traditional C++, C++ for the DDS-PSM-Cxx, and Java are provided in the following subclauses. Implementations are only required to support keys of types UInt32, UInt64, and String<Char8>. Implementations may choose to support other key types; however, to reduce complexity, maps declared to use any other key type may not be declared as an anonymous type in the IDL. If a Type Representation compiler encounters an anonymous map with key type that it does not support, it shall fail with an error. In section 7.5.1.3 'Map Types' add the following subsections before the first subsection (7.5.1.3.1 C++): (Note: the included tables shall be created in the same manner as all other tables in the document and not as represented here) 7.5.1.3.1 Operations Map types support operations to create, delete, and manipulate their contents. These operations are described in the following table. Each of the language bindings support logically equivalent operations which are further described below if they are not supported natively by the language. Table X. Operations for map<KeyType, ElementType> � map<KeyType, ElementType> � � Operations � new <return value> map<KeyType, ElementType> delete <return value> void initialize <return value> void finalize <return value> void copy <return value> ReturnCode_t � source map<KeyType, ElementType> � autogrow Boolean get_size <return value> unsigned int get_max_size <return value> unsigned int set_max_size <return value> ReturnCode_t � max_size unsigned int clear <return value> void insert <return value> ReturnCode_t � key KeyType � element ElementType insert_or_assign <return value> ReturnCode_t � key KeyType � element ElementType erase <return value> DDS_ReturnCode_t � key KeyType get_first <return value> MapEntry get_next <return value> Boolean � inout: entry MapEntry find_element <return value> ElementType � key KeyType find_entry <return value> MapEntry � key KeyType get_pair <return value> Boolean � entry MapEntry � out: key KeyType � out: element ElementType 7.5.1.3.2 C This mapping extends the IDL to C language mapping defined in [C-MAP]. Map types shall be represented as a collection of structures that contain a member of the key type followed by a member of the element type. A set of methods which create, delete and manipulate objects of the map type shall also be generated. The name of the map type is specified in this language binding. 7.5.1.3.2.1 Map Type Name For maps whose key type is a Primitive Type the name of the map type shall be constructed by combining the key type name with the element type name. The combination shall follow the schema below: [key_type][fully_qualified_element_type]Map For example, the names of the maps with element type Foo for each of the three mandatory key types would be: StringFooMap UInt32FooMap UInt64FooMap The concrete language binding is not specified, implementors may choose any language binding (e.g. a structure or a sequence) as long as its name and operations comply with what is specified here. For any type "T", the declaration and implementation of the map types having element type "T" and key types UInt32, UInt64, and String shall be generated alongside the implementation code for element type "T". Note: each of the following operations except for new take the map to be operated on as the first parameter. 7.5.1.3.2.2 Operation: new Allocate a new map. If this operation fails in an implementation-specific way, this operation shall return NULL. 7.5.1.3.2.3 Operation: delete Delete the map and all of its contents. 7.5.1.3.2.4 Operation: initialize Initialize the map. The initial size and capacity of the map shall be 0. 7.5.1.3.2.5 Operation: finalize Finalize the map. The entries in the map will be deleted, and both the size and maximum size set to 0. This is equivalent to calling clear() followed by set_max(0). 7.5.1.3.2.6 Operation: copy Overwrite the contents of this (destination) map with the contents of another (source) map. Any entries that are not present in the source map are erased from the destination map. The source map shall not be modified by this operation. If the size of the source map is greater than the maximum size of the destination map the behavior depends on the autogrow parameter. If autogrow is TRUE, the operation shall grow the maximum size of the destination map as needed. If autogrow is FALSE, the operation shall fail and return DDS_RETCODE_PRECONDITION_NOT_MET. In this case the destination map shall remain unchanged. If the size of the source is less than the maximum size of the destination then it is left to the implementation to decide whether the maximum size of the destination map is trimmed to match the source or left unchanged. If this operation fails in an implementation-specific way, the operation shall return DDS_RETCODE_ERROR. Parameter source - The map whose contents are to be copied. If this argument is NULL, the operation shall fail with DDS_RETCODE_BAD_PARAMETER. Parameter autogrow - Controls the behavior in case the destination map max_size is insufficient to hold the source map. 7.5.1.3.2.7 Operation: get_size Get the current size of the map. The size of the map is how many entries are currently present in the map. 7.5.1.3.2.8 Operation: get_max_size Get the current maximum size of the map. The maximum size limits the number of entries the map may contain. 7.5.1.3.2.9 Operation: set_max_size Set the maximum size of the map. This operation shall fail with DDS_RETCODE_ERROR if it fails for any implementation-specific reason. Parameter max_size - The new maximum size of the map. If the new max_size is less than the current size of the map the operation shall fail and return DDS_RETCODE_BAD_PARAMETER. 7.5.1.3.2.10 Operation: clear Clear all of the entries from the map. The size of the map is set to 0 and the maximum size does not change. 7.5.1.3.2.11 Operation: insert Insert a new entry into the map with the given key and element values. If the key already exists in the map the operation shall fail and return DDS_RETCODE_BAD_PARAMETER. If successful the size shall be increased by 1. If inserting a new entry into the map would increase the size past the current maximum size, then this operation shall fail with DDS_RETCODE_PRECONDITION_NOT_MET. This operation shall fail with DDS_RETCODE_ERROR if it fails for any implementation-specific reason. Parameter key - The key value of the entry to insert. If this argument is NULL, this operation shall fail and return DDS_RETCODE_BAD_PARAMETER. For keys with primitive types, this argument shall be generated as the type and not as a pointer to the primitive type. Parameter element - The element value of the entry to insert. If this argument is NULL, this operation shall fail and return DDS_RETCODE_BAD_PARAMETER. For elements with primitive types, this argument shall be generated as the type and not as a pointer to the primitive type. 7.5.1.3.2.12 Operation: insert_or_assign Insert an entry into the map with the given key and element values. If the key already exists in the map then the corresponding element shall be replaced. If the key value did not already exist in the map then the entry shall be inserted with the same behavior specified for the insert operation. This operation shall fail with DDS_RETCODE_ERROR if it fails for any implementation-specific reason. Parameter key - The key value of the entry to insert. If this argument is NULL, this operation shall fail and return DDS_RETCODE_BAD_PARAMETER. For keys with primitive types, this argument shall be generated as the type and not as a pointer to the primitive type. Parameter element - The element value of the entry to insert. If this argument is NULL, this operation shall fail and return DDS_RETCODE_BAD_PARAMETER. For elements with primitive types, this argument shall be generated as the type and not as a pointer to the primitive type. 7.5.1.3.2.13 Operation: erase Remove the entry with the given key from the map. If successful, the size of the map shall be decreased by 1. Parameter key - The key value of the entry to erase. If this argument is NULL, this operation shall fail and return DDS_RETCODE_BAD_PARAMETER. For keys with primitive types, this argument shall be generated as the type and not as a pointer to the primitive type. 7.5.1.3.2.14 Operation: get_first Retrieves a MapEntry referencing the first entry in the map. The returned MapEntry may be a sentinel if the map is empty. 7.5.1.3.2.15 Operation: get_next Advance the MapEntry to the next entry in the Map. If the MapEntry was referencing the last entry the MapCursor will be advanced to a sentinel and the operation will return FALSE, otherwise it will return TRUE. 7.5.1.3.2.16 Operation: find_element Retrieve the element whose key matches the specified one from the map. If the key exists then return the element corresponding to the key, otherwise return NULL. Parameter key - The key value of the element to search for. If this argument is NULL, this operation shall fail and return DDS_RETCODE_BAD_PARAMETER. For keys with primitive types, this argument shall be generated as the type and not as a pointer to the primitive type. 7.5.1.3.2.17 Operation: find_entry Retrieve the MapEntry whose key matches the specified one from the map. If the key exists then return a MapEntry referencing the entry (key and element) otherwise return a sentinel. Parameter key - The key value of the element to search for. If this argument is NULL, this operation shall fail and return DDS_RETCODE_BAD_PARAMETER. For keys with primitive types, this argument shall be generated as the type and not as a pointer to the primitive type. 7.5.1.3.2.18 Operation: get_pair Retrieve the key and element associated with the MapEntry. If the MapEntry was a sentinel the operation will return FALSE, otherwise it will return TRUE and fill the output parameters with references to the key and element. Parameter entry - The MapEntry whose key and element we wish to retrieve. If this argument is NULL, this operation shall fail and return DDS_RETCODE_BAD_PARAMETER. Parameter key (output) - The key value associated with the MapEntry. If this argument is NULL, this operation shall fail and return DDS_RETCODE_BAD_PARAMETER. Parameter element (output) - The element value associated with the MapEntry. If this argument is NULL, this operation shall fail and return DDS_RETCODE_BAD_PARAMETER. 7.5.1.3.2.19 Example (Non-Normative) For a struct MyElementType defined by the IDL: // IDL definition module MyModule { struct MyElementType { // ...members }; }; The following structures and operations should be generated for map<unsigned long, MyElementType>: struct UInt32MyModule_MyElementTypeMapElement { uint32_t key; MyModule_MyElementType element; }; typedef sequence<UInt32MyModule_MyElementTypeMapElement> UInt32MyModule_MyElementTypeMap; // Operations on UInt32MyModule_MyElementTypeMap UInt32MyModule_MyElementTypeMap* UInt32BarMap_new(); void UInt32MyModule_MyElementTypeMap_delete( UInt32MyModule_MyElementTypeMap *map); void UInt32MyModule_MyElementTypeMap_initialize( UInt32MyModule_MyElementTypeMap *map); void UInt32MyModule_MyElementTypeMap_finalize( UInt32MyModule_MyElementTypeMap *map); DDS_ReturnCode_t UInt32MyModule_MyElementTypeMap_copy( UInt32MyModule_MyElementTypeMap *map, UInt32MyModule_MyElementTypeMap *other, bool autogrow); uint32_t UInt32MyModule_MyElementTypeMap_get_size( UInt32MyModule_MyElementTypeMap *map); DDS_ReturnCode_t UInt32MyModule_MyElementTypeMap_set_size( UInt32MyModule_MyElementTypeMap *map, uint32_t size); uint32_t UInt32MyModule_MyElementTypeMap_get_max_size(); DDS_ReturnCode_t UInt32MyModule_MyElementTypeMap_set_max_size( UInt32MyModule_MyElementTypeMap *map, uint32_t max_size); void UInt32MyModule_MyElementTypeMap_clear(); DDS_ReturnCode_t UInt32MyModule_MyElementTypeMap_insert( UInt32MyModule_MyElementTypeMap *map, uint32_t key, MyModule_MyElementType *element); DDS_ReturnCode_t UInt32MyModule_MyElementTypeMap_insert_or_assign( UInt32MyModule_MyElementTypeMap *map, uint32_t key, MyModule_MyElementType *element); DDS_ReturnCode_t UInt32MyModule_MyElementTypeMap_erase( UInt32MyModule_MyElementTypeMap *map, uint32_t key); MapEntry UInt32MyModule_MyElementTypeMap_get_first( UInt32MyModule_MyElementTypeMap *map ); bool UInt32MyModule_MyElementTypeMap_get_next( UInt32MyModule_MyElementTypeMap *map, MapEntry *entry); MyElementType* UInt32MyModule_MyElementTypeMap_find_element( UInt32MyModule_MyElementTypeMap *map, uint32_t key ); MapEntry UInt32MyModule_MyElementTypeMap_find_entry( UInt32MyModule_MyElementTypeMap *map, uint32_t key ); bool UInt32MyModule_MyElementTypeMap_get_pair( UInt32MyModule_MyElementTypeMap *map, MapEntry *entry, uint32_t *key, MyElementType **element); Replace section 7.5.1.3.1 (C++) and its contents with the following 2 sections: *7.5.1.3.3 Traditional C++ * *7.5.1.3.4 Modern C++ * 7.5.1.3.3 Traditional C++ This mapping extends the IDL to C++ language mapping defined in [C++-MAP]. This C++ language binding differs only slightly from the C language binding. Instead of a C structure with accompanying functions, C++ defines a class with methods. 7.5.1.3.3.1 Map Class Name and operations The map class shall be named the same as the C structure, see 7.5.1.3.2.1, except that it is placed in the same namespace as the element type declaration. For example, the XTYPES map with key of type UInt32 and element type "MyElementType" belonging to module "MyModule" would be bound to the class: namespace MyModule { class UInt32MyElementTypeMap { public: UInt32MyElementTypeMap(); ~UInt32MyElementTypeMap(); ReturnCode_t copy( const UInt32MyElementTypeMap &other, bool autogrow = true); uint32_t get_size() const; ReturnCode_t set_size(uint32_t size); uint32_t get_max_size() const; ReturnCode_t set_max_size(uint32_t max_size); void clear(); ReturnCode_t insert( uint32_t key, const MyElementType &element, bool replace = true ); ReturnCode_t erase( uint32_t key ); MapEntry get_first(); bool get_next(MapEntry &entry); MyElementType* find_element( uint32_t key); MapEntry find_entry( uint32_t key ); bool get_pair( const MapEntry &entry, uint32_t *key, MyElementType **element); }; }; Refer to the C language binding for the behavior of each of the above methods, with the exceptions described below. The C++ operation insert behaves as the C insert if the replace parameter is false and it behaves as the C insert_or_assign if replace parameter is true. 7.5.1.3.4 Modern C++ This mapping extends the IDL to C++ language mapping defined in [DDS-PSM-Cxx]. The Map type shall be bound to an instantiation of the std::map template. The C++ Standard [C++-LANG] defines the std::map container as follows: namespace std { template<class Key, class T, class Compare = less<Key>, class Allocator = allocator<pair<const Key,T> > > class map; } The std::map template shall be instantiated with the "K" class parameter being the C++ type corresponding to the key type and the T parameter is the C++ type corresponding to the element type. When a map has keys of a string type, the Compare function shall operate on the character contents of the strings; it shall not operate on the strings? pointer values (as std::less does). The instantiations for the Compare and Allocator parameters are otherwise undefined and may or may not take their default values. For example, the XTYPES map with key of type UInt32 and element type "MyElementType" belonging to module "MyModule" would be bound to the following template instantiation: std::map<uint32_t, MyModule::MyElementType *>
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18305: Not every application limits itself to only 1 representation of a topic (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Revision
Severity: Significant
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.

Resolution: 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.
Revised Text:
Actions taken:
December 12, 2012: received issue
April 25, 2014: closed issue

Issue 18306: DataRepresentationQosPolicy is making the application responsible for transport (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Significant
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.

Resolution: Issue was withdrawn by the originating company Upon discussion during RTF the issue was withdrawn by the originating company.
Revised Text:
Actions taken:
December 12, 2012: received issue
April 6, 2017: Closed; No Change
June 22, 2017: closed issue

Issue 18307: Multiplicity mismatch between TypeName and TypeObject (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Minor
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?

Resolution: 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
Revised Text: At the end of Annex A replace the definition of TypeObject with the one below: @Extensibility(MUTABLE_EXTENSIBILITY) struct TypeObject { @Shared TypeLibrary library; TypeId the_type; }; At the end of section 7.6.2.2 (Discovery-Time Data Typing), add the following non-normative note: Non-normative note: When the TypeObject member (called type) is omitted from the built-in topic samples, type_name is the only way to resolve entity matching and as a consequence, it is possible that incompatibility between topic-types is not detected.
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18308: Topic incosisstency only considered for incompatible types, not for incompatible qos (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.)
Revised Text:
Actions taken:
December 12, 2012: received issue
April 6, 2017: Closed; No Change
June 22, 2017: closed issue

Issue 18309: lookup_topicdescription semantics make it unusable (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Minor
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.

Resolution: 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.
Revised Text: As defined in [DDS], a local TopicDescription object is uniquely identified by its name. In implementations conforming to this specification, that restriction shall be removed. The definition of lookup_topicdescription operation shall be modified from the one in the [DDS] specification as follows. The lookup_topicdescription operation shall accept an optional in unsigned long argument called index. This shall be the last argument. When the operation is called with only topic_name. It shall behave as if called with index = 0. When the operation is called with both a topic_name and an index, the operation shall return one of the TopicDescription associated with the DomainParticipant with a matching topic_name. The value of the index parameter shall be treated as an ?iterator? over the sequence of TopicDescription instances that match that topic_name. Each value of the index shall return a unique (different) TopicDescription. Values of the index from 0 to one less than the number of different TopicDescriptions match the topic_name shall return a TopicDescription and values of the index outside the range shall return nil.
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18310: Builtin topics not backward compatible (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Mr. Erik Hendriks, erik.hendriks(at)adlinktech.com)
Nature: Clarification
Severity: Significant
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.

Resolution: 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.
Revised Text: In Annex D modify definition of BuiltinTopicKey_t to match what follows: @Extensibility(EXTENSIBLE_EXTENSIBILITY) @Nested struct BuiltinTopicKey_t { octet value[16]; };
Actions taken:
December 12, 2012: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 18781: ths XSD has many errors (dds-xtypes-rtf)

Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Enhancement
Severity: Significant
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 'https://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 'https://www.omg.org/spec/DDS-XTypes/20120202/dds-xtypes_type_definition.xsd'."  W3C reference:   http://www.w3.org/TR/xmlschema11-1/#src-resolve

Resolution: 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="https://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.
Revised Text: In Section 7.3.2 XML Type Representatio edit the following paragraph: Types may be defined in an easy-to-read, easy-to-process XML format. This format is defined by an XML schema document (XSD) and a set of semantic rules, which are discussed below. The XML namespace of the XML Type Representation shall be formed by appending the OMG document number of this specification to the OMG HTTP domain in the following way: http:// www.omg.org/<issuing OMG subgroup>/<year>/<month>/<document ordinal>/<section_name>. For example, the namespace for the 1.0 version of this specification would be: http:// www.omg.org/ptc/2011/01/07/XML_Type_Representation http:// www.omg.org/dds. In section 7.3.2 and its subsections replace all (4) references to the namespace: "https://www.omg.org/ptc/2011/01/07/XML_Type_Representation" with rererences to: "https://www.omg.org/dds" Replace Annex A: XML Type Representation Schema with the following content: The following set of XML Schema Documents (XSD) formally defines the structure of XML documents conforming to the XML Type Representation. The first schema file, dds_types.xsd, declares the appropriate targetNamespace for this specification (i.e., [1]https://www.omg.org/dds), includes a schema containing the types definition called dds_types_definition.xsd, and defines the root element for XML documents containing type definitions.  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="https://www.omg.org/dds" targetNamespace="https://www.omg.org/dds" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="dds_types_definition.xsd" /> <xs:element name="types" type="typeLibrary"/> </xs:schema> The types definition schema file does not declare a targetNamespace, which makes it simpler for other specifications to include the schema file without having to deal with namespace declarations. This follows the so-called Chameleon Namespace Design, in which the schema with no targetNameSpace takes the "color" (namely, the targetNamespace) of the XSD file that includes it.  Paste here the contents of dds_types_definition.xsd Replace dds-xtypes_type_definition.xsd with the following XSD files (attached to this issue): *dds_types.xsd *dds_types_definition.xsd Include a new non-normative example XML file (attached to this issue): *dds_types.xml ---------------------------------------------------------------------------------------- [1] https://www.omg.org/dds
Actions taken:
June 17, 2013: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 19143: Annotation member default declaration not compatible with Legacy IDL (dds-xtypes-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Martin Corino, mcorino(at)remedy.nl)
Nature: Clarification
Severity: Significant
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.

Resolution: Merge with [1]DDSXTY12-122 [2]DDSXTY12-34 is to be addressed as part of the broader issue of aligning the XTypes specification with the IDL4 Specification ([3]DDSXTY12-122). ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY12-122 [2] http://issues.omg.org/browse/DDSXTY12-34 [3] http://issues.omg.org/browse/DDSXTY12-122
Revised Text:
Actions taken:
December 15, 2013: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 19144: IDL annotation syntax does specify how to use Any member type (dds-xtypes-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Martin Corino, mcorino(at)remedy.nl)
Nature: Clarification
Severity: Significant
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.

Resolution: 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".
Revised Text: In section 7.2.2.3.6 (Annotation Types) edit the bullests and remove the word "Any" from the beginning of each bullet. The resulting bullets are: *Primitive types *String types of Char8 or Char32 elements *Enumerated types
Actions taken:
December 15, 2013: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Discussion:

Issue 19145: IDL annotation syntax fails to specify soping rules for annotation type names (dds-xtypes-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Martin Corino, mcorino(at)remedy.nl)
Nature: Clarification
Severity: Significant
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.

Resolution: Combine with [1]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. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY12-34
Revised Text:
Actions taken:
December 15, 2013: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 19261: Specification document cleanup (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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.

Resolution: Incorporated corrections Document cleanup performed removing dangling elements and incorrect IDL structures.
Revised Text: Update Figure 39: removed reference to type_signature. Updated MapType, SequenceType, and StringType as follows. @Extensibility(MUTABLE_EXTENSIBILITY) @Nested struct MapType : CollectionType { @Extensibility(MUTABLE_EXTENSIBILITY) @Nested struct SequenceType : CollectionType { @Extensibility(MUTABLE_EXTENSIBILITY) @Nested struct StringType : CollectionType { Removed @ID(0x0075) @Optional DDS::StringSeq equivalent_type_name; @ID(0x0076) @Optional DDS::StringSeq base_type_name; from builtintopicdata structures as they are removed from the spec altogether via an older issue. the_type in TypeObject changed from sequence to _TypeId.
Actions taken:
February 26, 2014: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 19262: Send TypeId independently of the TypeObject (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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

Resolution: 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.
Revised Text: The parameter name for the optional _TypeId member in SubscriptionBuiltinTopicData, PublicationBuiltinTopicData, and TopicBuiltinTopicData is PID_TYPEID and its value shall be 0x0069.
Actions taken:
February 26, 2014: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 19263: TypeId union is missing NO_TYPE from the possible values of the discriminator (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution: Merged with [1]DDSXTY12-7 Merged with issue [2]DDSXTY12-7, which adds NO_TYPE case in _TypeId union. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY12-7 [2] http://issues.omg.org/browse/DDSXTY12-7
Revised Text:
Actions taken:
February 26, 2014: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 19264: The description for union types are not complete (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution: Duplicates [1]DDSXTY-12-5 Duplicates [2]DDSXTY-12-5 ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY-12 [2] http://issues.omg.org/browse/DDSXTY-12
Revised Text:
Actions taken:
February 27, 2014: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 19265: Issues with UNIONS assignability rules (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution: Duplicates [1]DDSXTY12-119 This issue is being merged into the a broader issue ([2]DDSXTY12-119) that seeks to make the assignability rules simpler and less restrictive. The resolution of [3]DDSXTY12-119 issue includes changes to the Union assignability rules which addressed the concerns [4]DDSXTY12-5 raises. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY12-119 [2] http://issues.omg.org/browse/DDSXTY12-119 [3] http://issues.omg.org/browse/DDSXTY12-119 [4] http://issues.omg.org/browse/DDSXTY12-5
Revised Text:
Actions taken:
February 26, 2014: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 19266: Spec should allow any value for the Optional flag in TypeObject union members (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution: Duplicates [1]DDSXTY12-11 Duplicates [2]DDSXTY12-11 ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY12-11 [2] http://issues.omg.org/browse/DDSXTY12-11
Revised Text:
Actions taken:
February 26, 2014: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 19267: TypeId calculation errors/corrections (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution: 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.
Revised Text: The new algorithm is as follows. 1. The typeid of primitive types is pre-defined and shall use the values predefined in Annex B. 2. The typeid of an AliasType shall be the typeid of its base_type. 3. The typeid for constructed types (i.e., StructureType, UnionType, AnnotationType, MapType, SequenceType, StringType, BitSetType, and EnumerationType) shall be computed applying the following rules: a) Construct an instance of the appropriate type-kind structure. b) The _TypeId in Type.property.type_id is set to{discriminator = NO_TYPE, constructed_type_id = NO_TYPE_ID} (i.e.{0, 0} ) c) The ObjectName in Type.property.name is set to the fully-qualified name for the type. The fully qualified name shall use the string ?::? (without quotations) as a module-name separator. d) The built-in annotations @Key, @Optional, @Shared, @UnionDefault that may appear in the Type definition are omitted from the AnnotationUsageSeq because they already appear in the Member.property.flag. e) The members in a *MemberSeq shall appear in the sequence in the ascending order of the member IDs. f) The annotations in an AnnotationUsageSeq shall appear in ascending lexicographic order of the annotation name. g) The case labels in a UnionCaseLabelSeq shall appear in ascending order of label value. h) The enumerated constants in an EnumeratedConstantSeq shall appear in ascending order of the enumeration element name. i) The Bits in a BitSeq shall appear in ascending order of bit position. j) The bounds in the BoundSeq in ArrayType shall appear in the left to right order as if the array bounds are written in IDL. k) The TypeProperty.name of CollectionTypes shall be the empty string. 2. Serialize the type-kind structure using Extensible Extensibility and big-endian CDR Data Representation without any encapsulation header. This step is recursive, as the serialization may require calculating the type IDs of referenced types?for example, structure members. 3. Apply the MD5 hash algorithm to that serialized representation of the type-kind structure. 4. The type ID is the last 8 bytes of the hash (highest memory address), converted into an unsigned 64-bit integer, such that the selected 64 bits from the hash match the big endian representation of the resulting unsigned integer .
Actions taken:
February 26, 2014: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 19268: Circular dependencies across types should be allowed (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

The XTypes spec does not make clear whether or not circular dependencies across types are allowed. They should be allowed.

Resolution: 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 [1]DDSXTY12-21. Essentially, circular dependencies are allowed but the m/w is not required to detect or warn against such uses. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY12-21
Revised Text:
Actions taken:
February 26, 2014: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 19269: Contradictions in the assignability for collection types (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
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).

Resolution: Merged with [1]DDSXTY12-119 This issue has been subsumed by [2]DDSXTY12-119. Therefore it should be merged into it. ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY12-119 [2] http://issues.omg.org/browse/DDSXTY12-119
Revised Text:
Actions taken:
February 26, 2014: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 19270: Deserialization issues with Extensible types (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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 the Connext version that we will ship to IN end of December.    Let's assume two Connext versions:    ????????? The IN Connext version that we will ship end of December (5.0.0.3)    ????????? A future Connext version (6.0) incorporating the changes to the XTypes spec described in the previous section    TOP-LEVEL Types    5.0.0.2 DataReaders should ignore the option bits set by the 6.0 DataWriters  6.0 DataWriters receiving samples from 5.0.0.2 DataReaders will assume that there are no padding bytes    MUTABLE Members    5.0.0.2 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.    6.0 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.

Resolution: 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.
Revised Text: In section 7.4.1.1 (Use of the (Traditional) OMG CDR Representation) At the end of the section, add the following paragraph: The [RTPS] specification states that following the serialized data submessage element, padding bytes shall be added so that the next submessage starts at a 4-byte offset relative to the beginning of the RTPS message. This XTYPES specification further requires that any padding bytes added at the end of the serialized data shall be set to zero. In section 7.4.1.2 (Parameterized CDR Representation) after the second paragraph which starts with "Each element or parameter..." add the following paragraph: Unlike it is stated in RTPS 2.2 subclause 9.4.2.11 "ParameterList", the value of the parameter length is the exact length of the serialized member. It does not account for any padding bytes that may follow the serialized member. Padding bytes may be added in order to start the next parameterID at a 4 byte offset relative to the previous parameterID. In section 7.6.2.1.2 (Use of the RTPS Encapsulation Identifier) modify the first paragraph as shown: As defined in the RTPS specification, a data encapsulation is identified by a two-byte value, the ?encapsulation identifier? [ RTPS ]. RTPS also identifiesdefines specific encapsulation identifier values corresponding to the encapsulations it definesfour encapsulations: big-endian CDR (CDR_BE), little-endian CDR (CDR_LE), big-endian parameter-list CDR (PL_CDR_BE), and little-endian parameter-list CDR (CDR_PL_LE). These encapsulations correspond to a choice of data representation and a byte-order encoding. In section 7.6.2.1.2 (Use of the RTPS Encapsulation Identifier) modify the second paragraph as shown: For the purposes of this specification, the two bytes of a representation identifier (an encapsulation identifier) shall be interpreted as a 16-bit unsigned big-endian integral value. Within the range of such a value (from zero [ 0x0000 ] to 65,535 [ 0xFFFF ] inclusive), the upper quartile (from 49,152 [ 0xC000 ] to 65,535 [ 0xFFFF ] inclusive)encapsulation identifiers where the first byte is in the range 0xC0 to 0xFF (both included) shall be reserved for definition by DDS implementations and shall be interpreted based on the RTPS vendor ID. The remainderremaining of the rangevalues for the Encapsulation Identifier shall be reserved for the OMG for use in future specifications, including revisions of this specification. In section 7.6.2.1.2 (Use of the RTPS Encapsulation Identifier) modify the third paragraph as shown: This specification adds an additional encapsulation identifier corresponding to the XML Data Representation: XML, with the value {0x00, 0x04} 0x0004. ( Since XML is a textual format, no byte-order differentiationqualification is necessary.) In section 7.6.2.1.2 (Use of the RTPS Encapsulation Identifier) at the end of the section add the following paragraphs: As defined in sub clause 10.2.1.2 titled ?OMG CDR? of the RTPS specification, the Encapsulation Identifier is followed by a 16-bit options field. The options field is then followed by the data encoded using CDR. The XML encapsulation identifier is also followed by a 16-bit options field, which shall precede the data serialized using the XML data representation described in sub clause 7.4.2. The RTPS specification does not define any settings for the 16-bit options field and further states that a receiver should not interpret it when it reads the options field. This DDS-XTYPES specification changes this defining the use of some bits in the options field. Implementations of this specification shall set the lower order two bits of the 16 bit options field to a value that encodes the number of padding bytes from the end of the serialized payload to the 4-byte aligned offset that will start the next RTPS submessage. Specifically the last two bits shall be set to binary 00 if there was no padding, binary 01 if there was one byte of padding, binary 10 if there were two bytes of padding and binary 11 if there were three bytes of padding. This shall be interpreted by the receiver to determine where the serialized data ended. For example assume structures typeA and typeB defined by the following IDL: struct TypeA { short member1; }; struct TypeB { short member1; char member2; }; Furthermore assume an object O1 of type TypeA with value O1.member1 = 0x11 and an object O2 of type TypeB with value O2.member1= 0x23 and O2.member2 = ?b?. The CDR big endian representation of these two objects, including Encapsulation header and options would be: Object O1 representation: 0...2...4.......8...............16..............24..............32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR_BE { 0x00, 0x00 } | options { 0x00, 0x02 } | +---------------+---------------+---------------+---------------+ | O1.member1 = 0x11 | padding (2 bytes) {0x00, 0x00}| +---------------+---------------+---------------+---------------+ NEXT RTPS SUBMESSAGE . . . Object O2 representation: 0...2...4.......8...............16..............24..............32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR_BE { 0x00, 0x00 } | options { 0x00, 0x01 } | +---------------+---------------+---------------+---------------+ | O2.member1 = 0x23 |O2.member2 =?b?| padding {0x00}| +---------------+---------------+---------------+---------------+ NEXT RTPS SUBMESSAGE . . .
Actions taken:
February 26, 2014: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 19271: Optional flag in TypeObject union members (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution: 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.
Revised Text: In section 7.3.4.4.3 (Unions) replace the last paragraph as shown: UnionType does not explicitly distinguish its discriminator member from its other members; doing so would be unnecessary, since by definition the discriminator is the first member and the only non-optional one. The discriminator union member is identified by being the one with member ID set to 0. It shall have the IS_OPTIONAL flag set to 0. It may have the IS_KEY flag set to 1 or 0 depending whether the Union has a key or not. The remaining union members shall have both the IS_OPTIONAL and the IS_KEY flags set to 0. In section 7.2.2.3.5.5 (Optional Members). Penultimate paragraph. Replace the sentence: The discriminator member of a union shall never be optional. The other members of a union shall always be optional. The designer of a structure can choose which members are optional on a member-by-member basis. With: Union members, including the discriminator, shall never be optional. Structure members may be optional. The designer of a structure can choose which members are optional on a member-by-member basis.
Actions taken:
February 26, 2014: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 19272: Mapping of optional arrays in C/C++ (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution: 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.
Revised Text: In section 7.5.1 'Plain Language Binding', right before subsection 7.5.1.1 'Primitive Types' add the following note Note that any of the following language bindings may be overridden in a language-specific PSM, such as DDS-PSM-Cxx. Move section 7.5.1.4.2 'Optional Members' and its subsections to section 7.5.1.2.4, in between section 7.5.1.2.3 'Shareable Members' and the current section 7.5.1.2.4 'Nested Types'. After this change 7.5.1.4.2 'Optional Members' becomes 7.5.1.2.4 'Optional Members' Then add the following section at the end (after section 7.5.1.2.4.3 'Java'): 7.5.1.2.4.4 Optional Arrays in C and C++ Optional arrays having element type "T" shall be mapped to type pointer-to-array-of-type-T rather than to type array-of-pointers-to-type-T. For example, the structure MyStruct containing an optional array of ten integers defined by the IDL: // IDL declarationstruct MyStruct { @optional long array_member[10]; }; Should be mapped in C and C++ to the type: // Mapping to C/C++struct MyStruct { int32_t (*array_member)[10]; } Without the parentheses, array_member is an array of ten int32_t pointers, rather than a pointer to an array of ten int32_t values.
Actions taken:
February 26, 2014: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue

Issue 19273: Optional flag in TypeObject union members (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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

Issue 19274: Allow empty structures (dds-xtypes-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution: 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.
Revised Text:
Actions taken:
February 26, 2014: received issue
April 6, 2017: Closed; Out Of Scope
June 22, 2017: closed issue

Issue 19405: Type Consistency Enforcement Policy does not allow to properly control type projection/widening (dds-xtypes-rtf)

Click here for this issue's archive.
Source: ADLINK Technology Ltd (Angelo Corsaro, PhD., angelo.corsaro(at)adlinktech.com)
Nature: Revision
Severity: Critical
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.

Resolution: Merged with [1]DDSXTY12-18 This issue is addressed by the same mechanism proposed to address [2]DDSXTY12-18 and therefore it is being merged with it. Even if it had been merged with [3]DDSXTY12-18 it was eventually handled by [4]DDSXTY12-145 which was resolved before [5]DDSXTY12-18 ---------------------------------------------------------------------------------------- [1] http://issues.omg.org/browse/DDSXTY12-18 [2] http://issues.omg.org/browse/DDSXTY12-18 [3] http://issues.omg.org/browse/DDSXTY12-18 [4] http://issues.omg.org/browse/DDSXTY12-145 [5] http://issues.omg.org/browse/DDSXTY12-18
Revised Text:
Actions taken:
May 2, 2014: received issue
April 6, 2017: Duplicate or Merged
June 22, 2017: closed issue

Issue 19587: One sentence split in two bullets (dds-xtypes-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
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.

Resolution: *Incorporated editorial changes * Editorial change in Section 7.2.2.3.7.1 bullet #4
Revised Text: The string ?*? (an asterisk) shall indicate that text applies to all programming languages.
Actions taken:
August 26, 2014: received issue
April 6, 2017: Resolved
June 22, 2017: closed issue