Issues for Extensible and Dynamic Topic Types for DDS Finalization Task Force 1.0 mailing list

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

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

Issue 15946: All IDL should use local interfaces
Issue 17018: Rendering of UML diagrams in each of the figures is of poor graphical quality
Issue 17293: Built-in annotations should be in DDS namespace
Issue 17294: Extended PID is not clear enough what the 2 value lengths mean
Issue 17295: Reserved parameter IDs in 7.4.1.2.1 are wrong
Issue 17296: Section 7.4.1.2.2 "Member ID-to-Parameter ID Mapping" is underspecified
Issue 17297: Extended parameters should be aligned the same as non-extended ones

Issue 15946: All IDL should use local interfaces (dds-xtypes-ftf)

All IDL should be using local interfaces, not regular interfaces, please add the keyword local to all interfaces

The only non-local interfaces in the DDS-XTypes API are specializations of “generic” interfaces defined by the DDS specification. It is not appropriate to change these to local interfaces until the corresponding change is made in the DDS specification itself. An issue has already been filed for the DDS RTF to make this change.
Disposition:	Deferred

The gradient shading rendered in each of the elements on a low-color image results in elements rendered as follows:

 
 
The diagrams should be rendered either by using a higher-color format (such as png), or without the gradient rendering enabled.
 
NB: To turn off the gradient shading in Enterprise Architect, go to the "Tools->Options" dialog. Under the "Diagram->Appearance" group:
1) Deselect the "Show Gradient Fill for Paper Color" option
2) Set the "Gradient Fill Direction for an Element" to "<none>"

To turn off the gradient shading in Enterprise Architect, go to the "Tools->Options" dialog. Under the "Diagram->Appearance" group:
1)	Deselect the "Show Gradient Fill for Paper Color" option
2)	Set the "Gradient Fill Direction for an Element" to "<none>"

Found by: Rick Warren, RTI (rick.warren@rti.com)
Severity: Minor


Problem:
The IDL Type Representation uses so-called "built-in annotations" to attach metadata to type definitions. The hypothetical module in which these annotations are defined is unclear. On the one hand, all (other) types defined by the specification are in the DDS:: module. However, in the case of the built-in annotations, no module is specified.


Proposed Resolution:
Clearly indicate that all built-in annotations are notionally in the DDS:: module

Found by: Fernando Crespo, RTI (fernando@rti.com)
Severity: Support Text


Problem:
Section 7.4.1.2.1, "Interpretation of Parameter ID Values", says the following directly beneath Table 27, "Reserved parameter ID values":


    "The length of this parameter shall be at least eight bytes: the first 
    four bytes of the parameter data shall be interpreted as a set of four 
    reserved bit flags followed by the 28-bit member ID; the second four
    bytes shall be interpreted as a 32-bit unsigned data length measured
    from the end of that field until the start of the next 16-bit parameter 
    ID. If the 16-bit length is greater than eight, the additional contents 
    are undefined and are reserved for future use by OMG specifications."


The meaning is that the "data value" of the (shorter) parameter is in fact itself a longer parameter ID header, and the length indicated in the former header is in fact the length of that (longer) header only. The actual data value follows both headers, and its length (i.e. until the next parameter header) is given in the longer parameter header. Thus the total length of the parameter following the shorter header is the sum of the two lengths. The values of the flag fields are unspecified, as of the 1.0 specification, and reserved for future OMG specifications.


Proposed Resolution:
Update the description to more clearly reflect the data layout and add a figure to show it graphically.

Found by: Fernando Crespo, RTI (fernando@rti.com)
Severity: Significant


Problem:
Table 27, "Reserved parameter ID values", in section 7.4.1.2.1, "Interpretation of Parameter ID Values", gives the 14-bit numeric IDs for the reserved parameters. However, it does not specify the corresponding values of the FLAG_IMPL_EXTENSION and FLAG_MUST_UNDERSTAND flags. The implication is that either flag may be set independently on an occurrence-by-occurrence basis, but that would be a bad idea: first of all, if FLAG_IMPL_EXTENSION is set, the specification should assume nothing about the contents of the parameter. And second of all, most parameters have a value of FLAG_MUST_UNDERSTAND that could reasonably be specified up front.


For example, and in particular, with respect to PID_EXTENDED, the text currently says: "The setting of the FLAG_MUST_UNDERSTAND bit in the 16-bit parameter ID shall be interpreted to apply to the extended parameter as well, not just to the 12 bytes of the PID_EXTENDED parameter itself." In other words, the flag is set based on the the must_understand attribute of a given member. This behavior is inappropriate, given that non-XTypes-conformant DDS implementations may receive extended parameters within discovery data: such implementations, if they do not see FLAG_MUST_UNDERSTAND set, will erroneously interpret the first four bytes of the (extended) data value as a parameter header, effectively corrupting the input data stream.


Proposed Resolution:
1. Clearly indicate that any parameter with FLAG_IMPL_EXTENSION set is outside of the scope of the specification. For a parameter to be recognized as one of the well-known values in the table, this bit must be set to zero.


2. Add a column to table 27 for the FLAG_MUST_UNDERSTAND flag. Set the value of this flag as follows:
    * PID_EXTENDED: Yes. This will force non-XTypes-conformant implementations 
      to discard data containing extended headers rather than parsing it 
      incorrectly.
    * PID_LIST_END: Yes. This will force implementations to either recognize 
      the end of the list or to discard the data. It will avoid a situation 
      where an implementation might "skip" the end of the list and start 
      parsing out of bounds.
    * PID_IGNORE: No. The whole point is to ignore this parameter.


3. When writing data, the Service shall conform to the setting of FLAG_MUST_UNDERSTAND indicated above. When reading data, the Service should be robust to the opposite setting as well and accept the parameter nevertheless.


4. Within the four-bit set of flags that has already been reserved within the extended parameter header, use the most-significant bit to indicate vendor-specific extensions and the second-most-significant-bit to represent the value of the must_understand value of a data member. These flags are parallel to the flags in the short parameter header and restore the flexibility lost by specifying up front the value of the corresponding flags in that header.


5. Do not leave the contents of the other flags in the extended parameter header with junk contents; if a given flag's value is not specified by some (other) OMG specification, it should be set to zero.

Found by: Fernando Crespo, RTI (fernando@rti.com)
Severity: Support Text


Problem:
The mapping of type member IDs to DDS-RTPS parameter IDs described in section 7.4.1.2.2, "Member ID-to-Parameter ID Mapping", will never result in FLAG_IMPL_EXTENSION being set. However, this is not stated explicitly.


Proposed Resolution:
Explicitly state that RTPS parameters corresponding to members of user-defined data types should never set FLAG_IMPL_EXTENSION.


RTPS parameters corresponding to members of RTPS discovery-defined data types may or may not have FLAG_IMPL_EXTENSION set as defined by RTPS itself; the contract is unchanged. The mechanism by which an implementation generates that flag's value is unspecified.

Found by: Fernando Crespo, RTI (fernando@rti.com)
Severity: Support Text


Problem:
The section on the parameterized CDR Data Representation (DDS-XTypes 7.4.1.2) contains a reference to the DDS-RTPS specification for the definition of the parameter list data structure. However, it does not specifically refer to the instructions in DDS-RTPS on how to handle alignment within such a structure. This omission may confuse some implementers, especially with respect to extended parameters, which should follow the same alignment rules as RTPS-traditional "short" parameters.


Proposed Resolution:
Add the following paragraph to the end of section 7.4.1.2.1, "Interpretation of Parameter ID Values":


    "The alignment rules for extended parameters shall be the same as
    those for non-extended parameters, which are defined in [RTPS]
    Section 9.4.2.11."