Extensible and Dynamic Topic Types for DDS Avatar
  1. OMG Specification

Extensible and Dynamic Topic Types for DDS — All Issues

  • Acronym: DDS-XTypes
  • Issues Count: 60
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSXTY12-41 Reserved parameter IDs in 7.4.1.2.1 are wrong DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-45 Extended PID is not clear enough what the 2 value lengths mean DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-40 Section 7.4.1.2.2 "Member ID-to-Parameter ID Mapping" is underspecified DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY12-42 Built-in annotations should be in DDS namespace DDS-XTypes 1.0b2 DDS-XTypes 1.2 Duplicate or Merged closed
DDSXTY12-44 Rendering of UML diagrams in each of the figures is of poor graphical quality DDS-XTypes 1.0b2 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-43 All IDL should use local interfaces DDS-XTypes 1.0b2 DDS-XTypes 1.2 Closed; No Change closed
DDSXTY12-39 Extended parameters should be aligned the same as non-extended ones DDS-XTypes 1.0b2 DDS-XTypes 1.2 Resolved closed
DDSXTY11-12 Not every application limits itself to only 1 representation of a topic DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-11 Semantics of overriding an attribute not clearly specified DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-10 Typo DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-9 Typo in opening sentence of section: Missing noun and verb DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY11-8 Inconsistent extensibility kind for enumerations DDS-XTypes 1.0 DDS-XTypes 1.1 Resolved closed
DDSXTY_-26 DynamicData interface of the Language Binding section DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-25 Inconsistent generated code for DynamicType::descriptor DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-24 Circular reference in definition of specialized Primitive Types DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-19 Introduce the notional value "null" that may be used in a content-filter expression DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-23 Invalid data types applied to AnnotationDescriptor::value, DynamicData::descriptor, DynamicData::value DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-22 Conflicting data types applied to several Attributes, Operations and Parameters in UML notation DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-21 Non-standard UML notation on figures DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-20 Truncation of text in Figure 3 DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-18 New DDS-XTypes issue: inability to consume data using new base class DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-17 Object assignability rules should be more resilient DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-16 Definition of “strongly assignable” is incomplete DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-12 Incorrect default extensibility kind value in XSD file DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-15 Incorrect union assignability rules DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-14 Inconsistent bit set/integer equivalency DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-13 Ambiguous description of serializing discovery types DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-9 Difficult to apply automation to statically defined types DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-8 Changing a DynamicType object is ambiguous DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-11 Optional, must_understand members of non-mutable aggregation types cannot be accurately represented in CDR DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-10 New QoS policies don’t indicate whether they can be changed DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-7 Typographical errors DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-6 Type signature fields in built-in topic data shouldn't use unbounded strings DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-5 No way to get or set length of collection-typed DynamicData objects DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-4 Annex D (“DDS Built-in Topic Data Types”) is out of sync with IDL file DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-3 C++ mapping MAP type needs member access semantics specification DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-2 Restrictions on MAP key element type not (clearly) documented/specified DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY_-1 Anonymous types should not be used in IDL examples and the TypeObject representation IDL DDS-XTypes 1.0b2 DDS-XTypes 1.0 Resolved closed
DDSXTY-29 Different applications in the same domain may associate the same Topic with different types DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-28 DDS-XTypes @Key annotation Issue DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-8 Can’t initialize TypeId from TypeKind DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-9 Identifiers TypeId and Module collide with IDL keywords DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-23 Don’t require CORBA namespace for primitive types in Plain Language Binding DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-22 Allow more flexible type consistency enforcement DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-21 Typographical errors DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-20 Mutable structures with an empty intersection should not be considered assignable DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-19 XML representations should define namespaces DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-25 Provide minimal backwards-compatible conformance point DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-24 Provide formal grammar for new IDL Type Representation constructs DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-27 Improve support for shared data DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-26 Reduce size of DynamicData API DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-16 Incorrect FooDataWriter overloads for built-in types DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-15 Missing definitions of TypeSupport specializations for built-in types DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-18 Allow IDL compatibility pragma declarations to nest DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-17 Consolidate IDL built-in annotations in machine-readable file DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-14 Updated QoS definitions should be provided DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-13 Extensibility kinds of new QoS policies are not specified in a consistent way DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-11 Unclear member names when programming language doesn’t support typedef DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-10 Definition of built-in IDL annotation @Shared is missing DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed
DDSXTY-12 Definition of type “Parameters” inadvertently missing DDS-XTypes 1.0b1 DDS-XTypes 1.0b2 Resolved closed

Issues Descriptions

Reserved parameter IDs in 7.4.1.2.1 are wrong

  • Legacy Issue Number: 17295
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Fix and clearly specify the values of flags for parameters reserved in section 7.4.1.2.1

    The values for flags FLAG_IMPL_EXTENSION and FLAG_MUST_UNDERSTAND are either not explicitly stated or are incorrect in section 7.4.1.2.1 "Interpretation of Parameter ID Values". We need to explicitly state the values and fix the values for extended parameters.

    To resolve modify teh specification according to the five steps described as "proposed resolution" in the issue description.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Extended PID is not clear enough what the 2 value lengths mean

  • Legacy Issue Number: 17294
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Clarify how to use PID_EXTENDED and add graphic

    The text describing how to use the PID_EXTENDED parameter ID needs clarification and a graphic.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Section 7.4.1.2.2 "Member ID-to-Parameter ID Mapping" is underspecified

  • Legacy Issue Number: 17296
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Explicitly State when FLAG_IMPL_EXTENSION cannot be used

    Problem description in DDSXTY12-40. There is no text explicitly stating that FLAG_IMPL_EXTENSION will never be set on user-defined data types. This clarifying text should be added to section 7.4.1.2.2

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Built-in annotations should be in DDS namespace

  • Legacy Issue Number: 17293
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    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

  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Duplicate or Merged — DDS-XTypes 1.2
  • Disposition Summary:

    Merge with DDSXTY12-34

    This can be treated together with DDSXTY12-34 which is already aligning annotations with the syntax of IDL4

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Rendering of UML diagrams in each of the figures is of poor graphical quality

  • Legacy Issue Number: 17018
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    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>"

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    This issue was already fixed on previous revisions

    The issue was in the adopted submission but it was resolved in version 1.0 and subsequent versions.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

All IDL should use local interfaces

  • Legacy Issue Number: 15946
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

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

  • Reported: DDS-XTypes 1.0b2 — Thu, 13 Jan 2011 05:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    No change needed as local interfaces are being deprecated in IDL4

    The use of IDL in XTYPES needs to be re-examined in light of IDL4. Specially features that are not part of the "DDS Profiles" defined in IDL4.

    XTYPES uses local interfaces to define the DynamicData and DynamicType interfaces. It also uses them to define annotations. XTYPES uses regular interfaces to define the TypeSupport interface. IDL4 local interfaces belong to the CORBA-Specific building block. They are not part of the "DDS Profiles"
    XTYPES uses (non-local) interfaces to define TypeSupport. This is in the RPC over DDS profile of IDL4.

    XTYPES uses valuetypes to describe parts of the DynamicData and DynamicType interfaces. These are part of the Building Block ValueTypes which is not in any of the the "DDS Profiles"
    Note that the fact that XTYPE uses a specific IDL building block (BB) does not mean that implementations of XTYPES that would end up having to support that BB. As long as that dependency on the BB is limited to describing interfaces that are "built into" the XTYPES DDS APIs there is no problem. If however they form part of the code being generated from user-defined datatypes then we would really have an issue.
    The issue with "local" interfaces is that IDL4 considers them deprecated and for that reason it included them in the CORBA module.

    The IDL4 view is that interfaces are just a contract specification, whether they are local or not is more up for interpretation by a particular use of the IDL. Hence this is specified via annotations like @service(DDS) or @service(CORBA). Therefore if an interface does not state anything it can be interpreted as a "local" interface...

    So while the current use of local interfaces and valuetypes on XTYPES appears fine, it may make sense (in light of IDL4) to actually remove all use of "local" interfaces replacing them with regular interfaces...

    However at this point it seems best to leave things as they are and wait for the alignment with IDL4...

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Extended parameters should be aligned the same as non-extended ones

  • Legacy Issue Number: 17297
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    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."

  • Reported: DDS-XTypes 1.0b2 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    Specify alignment of Extended Parameters

    Accept the suggestion from the issue description.

  • Updated: Thu, 22 Jun 2017 16:42 GMT

Not every application limits itself to only 1 representation of a topic

  • Legacy Issue Number: 18305
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • 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.

  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:43 GMT

Semantics of overriding an attribute not clearly specified

  • Legacy Issue Number: 18299
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • 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.

  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 04:43 GMT

Typo

  • Legacy Issue Number: 18296
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

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

  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    Corrected sentence: For the same sake of run-time efficiency …

  • Updated: Sat, 7 Mar 2015 04:43 GMT

Typo in opening sentence of section: Missing noun and verb

  • Key: DDSXTY11-9
  • Legacy Issue Number: 18294
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • 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.

  • Reported: DDS-XTypes 1.0 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    Corrected sentence: System developers frequently require the ability to inject their own text into the code produced by a Type Representation compiler.

  • Updated: Sat, 7 Mar 2015 04:43 GMT

Inconsistent extensibility kind for enumerations

  • Key: DDSXTY11-8
  • Legacy Issue Number: 16559
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification of the extensibility kind for enumeration types is inconsistent. Figure 10 in section 7.2.2.3.1, "Enumeration Types", indicates that the extensibility_kind of all enumeration types is FINAL. However, Table 11 in section 7.2.3, "Type Extensibility and Mutability", says, "Enumeration types may be final, extensible, or mutable on a type-by-type basis."

    Proposed Resolution:

    The assignability rules for enumerations already address different extensibility kinds, so we can preserve the more general statement from 7.2.3. Fix Figure 10.

  • Reported: DDS-XTypes 1.0 — Mon, 19 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.1
  • Disposition Summary:

    The assignability rules for enumerations already address different extensibility kinds, so we can preserve the more general statement from 7.2.3. Fix Figure 10.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

DynamicData interface of the Language Binding section

  • Key: DDSXTY_-26
  • Legacy Issue Number: 15418
  • Status: closed  
  • Source: Brookhaven National Laboratory ( Nikolay Malitsky)
  • Summary:

    First, thank you for this specification. It provides a systematic and comprehensive definition of the runtime type system which is important in the context of the next version of Experimental Physics and Industrial Control System (http://www.aps.anl.gov/epics/). Moreover, from my perspective, the conceptual idea of the dynamic container is more generic than DDS and EPICS and addresses other technologies, like AMQP. In this regard, I have several suggestions for the DynamicData interface of the Language Binding section, particularly, to scale down the number of methods from 270 to 30 and to replace the 'out' arguments with return values.

    At this time, we are working on the prototype of this variant based on the consolidation of several approaches, including DDS Dynamic Data, Google's Protocol Buffers, etc. Certainly, for us, it would be ideal to have some common solution. According to the Beta 1 procedure, OMG will accumulate comments by November 29. But, probably, it can be discussed earlier, for example, at the coming OMG technical meeting. Please advise.

  • Reported: DDS-XTypes 1.0b2 — Mon, 16 Aug 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    non issue, closed

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Inconsistent generated code for DynamicType::descriptor

  • Key: DDSXTY_-25
  • Legacy Issue Number: 17090
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    DynamicType has a property "descriptor" of type (read-only) TypeDescriptor. This property is mapped to IDL as a readonly attribute. When code is generated for this attribute in C or C++, the corresponding getter is not consistent with the other getters in the same class, either in terms of its style or in terms of its memory management. (The other getters are all defined explicitly as methods in IDL.)

    Proposed Resolution:
    Remove this member and add an explicit getter method:

    DDS::ReturnCode_t get_descriptor(
    inout TypeDescriptor descriptor);

    This method overwrites a user-provided object, just like get_member_by_name and get_annotation.

  • Reported: DDS-XTypes 1.0b2 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Remove these attributes and add explicit getter methods, like:
    DDS::ReturnCode_t get_descriptor(
    inout TypeDescriptor descriptor);
    This method overwrites a user-provided object, just like DynamicType::get_member_by_name and get_annotation

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Circular reference in definition of specialized Primitive Types

  • Key: DDSXTY_-24
  • Legacy Issue Number: 17023
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The specialized Primitive Types defined for Int, UInt, Float, Boolean, etc... each define a property 'value' that is typed by the property's owner thus resulting in a circular reference in the model.

    Figure 6
    Figure 7
    Figure 8

    Each of these are specializations of the PrimitiveType abstract class. Changing the UML instance of the PrimitiveType definition to a UML:PrimitiveType will automatically convey the semantic that an instance of the specialized PrimitiveType is the value itself.

    NB: To do this in Enterprise Architect recreate the PrimitiveType abstract definition as an instance of the 'Primitive' element found in the 'Class' toolbox.

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Remove the value members

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Introduce the notional value "null" that may be used in a content-filter expression

  • Key: DDSXTY_-19
  • Legacy Issue Number: 16720
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification introduces the concept of optional members into DDS data types. However, it does not address how comparisons of these members should work in content-filtering expressions. For example, if a content-filtered topic indicates that all samples are of interest where "x != 5", but x is not present in the sample at all, does the sample pass the filter or not?

    Proposed resolution: Introduce the notional value "null" that may be used in a content-filter expression. The null value is not equal to any value in the domain of any data type. (That is, x != null for any non-null value of x.) A member's value in a given sample shall be considered to be equal to null if that member is not present in the given sample. Its value shall not be considered equal to null if it is present.

  • Reported: DDS-XTypes 1.0b2 — Mon, 21 Nov 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Optional members:
    Introduce the notional value “null” that may be used in a content-filter expression. The null value is not equal to any value in the domain of any data type. (That is, x != null for any non-null value of x.)
    • An optional member’s value in a given sample shall be considered to be equal to null if that member is not present in the given sample.
    • Its value shall not be considered equal to null if it is present.
    • A non-optional member’s value shall never be considered equal to null.
    Maps:
    Use the same syntax as arrays and sequences, but instead of a numeric index, use the stringified representation of the key to be queried as a string literal. Such an expression evaluates to the “value” element of the map that is associated with the given key. For example:
    my_map['foo'] = 'bar'
    my_map['5'] = 'baz'
    Bit sets:
    Use the same syntax as arrays and sequences, but instead of a numeric index, use the enumerated constant identifying the desired bit. Such an expression evaluates to a Boolean value: true if the named bit is set or false if it is not. For example:
    my_bitset['MY_BIT_CONSTANT']
    Specify the above rules in a new section 7.6.5, “DCPS Queries and Filters”. Include the relevant updates to the DCPS Queries and Filters grammar (from Annex A in the DDS 1.2 specification).
    In addition, include a description of the following things that should be described in DDS already but seem to be missing:
    • The use square bracket syntax for arrays, strings, and sequences
    • Boolean literals
    An issue should be filed against DDS for this, but the resolution of this issue should not wait for it to be acted upon.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Invalid data types applied to AnnotationDescriptor::value, DynamicData::descriptor, DynamicData::value

  • Key: DDSXTY_-23
  • Legacy Issue Number: 17022
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The above-mentioned attributes (Figures 28 and 37) have types defined in the form "xxx --> yyy" which has no meaning in UML. Please clarify and correct.

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Change the type of AnnotationDescriptor::value to Map<String, String>.
    Unify the property DynamicData::descriptor with the existing association to MemberDescriptor, and qualify this association by MemberId.
    Change the property DynamicData::value to an association to Type, and qualify this association by MemberId.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Conflicting data types applied to several Attributes, Operations and Parameters in UML notation

  • Key: DDSXTY_-22
  • Legacy Issue Number: 17021
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The following figures exhibit inconsistent application of data types to attributes, operations and parameters:
    Figure 4
    Figure 9
    Figure 10
    Figure 13
    Figure 14
    Figure 16
    Figure 26
    Figure 30
    Figure 33
    Figure 36
    Figure 37
    Figure 38
    Figure 39

    Certain attributes/parameters have 'int' or 'string' applied which conflict the data types defined within the aforementioned model, and the PrimitiveTypes defined in UML. What is the intent with these? Which set of primitive data types are intended for application here (IDL? Java, C++, UML, XTypes?)

    For example, the 'Enumeration' class in Figure 10 defines a 'bit-bound' property of type int.

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Use DDS-XTypes types consistently. Note that Figures 9 and 16 are already correct—they use the DDS-XTypes-derived basic types, not the UML-built-in ones.
    Note that if the resolution to issue #16561 is accepted, the modification to figure 38 will be irrelevant, because the corresponding section of the document will be removed.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Non-standard UML notation on figures

  • Key: DDSXTY_-21
  • Legacy Issue Number: 17020
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The following figures exhibit non-standard notation for specialized elements:
    Figure 4
    Figure 9
    Figure 11
    Figure 14
    Figure 16
    Figure 17
    Figure 20

    The textual notation showing generalized elements on specialized ones needs to either be hidden, or have the generalized element explicitly shown on the diagram (with generalization relationship between the elements showing).

    NB: To hide the generalized element names on specialized ones in Enterprise Architect, double-click on a blank area of the diagram to open the Diagram Properties Dialog. On the "Diagram" tab deselect the "Show additional Parents" option.

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Figures 4, 6–9, 12, 13, 15, 16, 17, 20, and 38: Simply hide the additional parents, as described above. Note that if the resolution to issue #16561 is accepted, the modification to figure 38 will be irrelevant, because the corresponding section of the document will be removed.
    Figures 10, 11, and 14: Add class “Namespace” to the diagram.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Truncation of text in Figure 3

  • Key: DDSXTY_-20
  • Legacy Issue Number: 17019
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    The first rectangular symbol in Figure 3 contains truncated text - Type Representation

  • Reported: DDS-XTypes 1.0b2 — Thu, 19 Jan 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Fix the truncated text

  • Updated: Fri, 6 Mar 2015 21:48 GMT

New DDS-XTypes issue: inability to consume data using new base class

  • Key: DDSXTY_-18
  • Legacy Issue Number: 16561
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    have a new issue to file against the DDS-XTypes spec that was pointed out to me by Reinier Torenbeek.

    Declared compatibility of types (i.e. type signature) includes base types but not derived types. Unfortunately, that means that a consumer using a base class unknown to an existing producer will not be able to consume data from that producer, because neither party will declare the relationship between the types.

    For example: I publish Dog, which extends Animal. In version 2, a new intermediate class Mammal is introduced. However, a new consumer of Mammal won't match with a legacy producer of Dog, because both the Dog and Mammal endpoints declare that their types extend Animal, and neither one asserts that Dog should now extend Mammal.

    Proposed Resolution:

    Remove the type signature concept and go back to registering simple names. In its place, introduce a new QoS policy that lists assertions about which types extend which others. Consider making these assertions transitive. As today, the operative set of assertions when matching producers and consumers should be the union between the producer's and the consumer's sets.

  • Reported: DDS-XTypes 1.0b2 — Tue, 20 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Remove the type signature concept and go back to registering simple names

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Object assignability rules should be more resilient

  • Key: DDSXTY_-17
  • Legacy Issue Number: 16368
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    Source:

    RTI (Mr. Alejandro de Campos, alejandro@rti.com)

    Summary:

    A small object-level assignability problem within a complex sample can result in an entire sample being discarded. For example, a string whose length is greater than the bound of a string it’s being assigned into must be discarded. A sequence with an unassignable member must be discarded. A structure with an unassignable member must be discarded. As a result, a small issue deep within a structure could cause a whole sample to be discarded. For example, an issue within a TypeObject could result in an entire built-in topic data sample being discarded and consequently a loss of discovery information.

    Discussion:

    If we attempt to prevent any possible semantic problem that could arise from partial samples, we will have to keep the existing draconian rules, which can have bigger impacts, as described above. Therefore, the rules should seek to be more lenient and allow type-aware code “above” the assignability algorithm to detect semantic problems.

    Proposed Resolution:

    The following are the cases identified in the specification in which individual objects may be unassignable:

    · Strings that are too long: No change. Strings are a basic type, and truncation can generally not be easily detected by applications.

    · Arrays with unassignable elements: No change. In CDR, arrays have no length or other means of delimiting elements, so it is not possible to “truncate” them.

    · Sequences that are too long or contain unassignable elements: Discard only the offending elements, “left-shifting” subsequent elements and reducing the length as necessary.

    · Maps that are too long or contain unassignable elements: No change. Map entries are not logically ordered, so elements may not be discarded in a stable fashion.

    · Enumeration with unrecognized value: No change.

    · Union whose discriminator does not select a value in the destination type: No change—otherwise, the union would be malformed.

    · Structure with a “must understand” member not present in the destination type: No change—otherwise, the union would be malformed.

    Add the following new rules:

    · Structure with an unassignable non-optional member: The entire structure is considered unassignable. (This behavior was previously underspecified.)

    · Structure with an unassignable option member: The member takes no value. The rest of the structure can theoretically be retained.

  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    The following are the cases identified in the specification in which individual objects may be unassignable along with the changes to be made, if any:
    • Strings that are too long: If the bound of a string increases, the string is unassignable. Strings are a basic type, and truncation can generally not be easily detected by applications.
    • Arrays with unassignable elements: No change. In CDR, arrays have no length or other means of delimiting elements, so it is not possible to “truncate” them.
    • Sequences that are too long or contain unassignable elements: If the bound of a sequence increases, or an element is unassignable, the whole sequence is unassignable. Applications have little ability to detect or mitigate sequence truncation, so automatic truncation is undesirable.
    • Maps that are too long or contain unassignable elements: If the bound of a map increases, or an element is unassignable, the whole map is unassignable. Applications have little ability to detect or mitigate map truncation, so automatic truncation is undesirable.
    • Enumeration with unrecognized value: No change.
    • Union whose discriminator does not select a value in the destination type: No change—otherwise, the union would be malformed.
    • Structure with a “must understand” member not present in the destination type: No change—otherwise, the structure would be malformed.
    Add the following new rules for structures, which cover behavior that was previously underspecified:
    • An unassignable non-optional member: The entire structure is considered unassignable.
    • An unassignable optional member: The member takes no value. The rest of the structure can be retained.
    • Mismatched “optional” attribute in a final or extensible structure: The types are not assignable. This restriction is necessary because of the header that precedes such members.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Definition of “strongly assignable” is incomplete

  • Key: DDSXTY_-16
  • Legacy Issue Number: 16367
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The definition of the term “strongly assignable” in section 7.2.4, Type Compatibility: “is-assignable-from” relationship, states:

    If types T1 and T2 are both mutable and T1 is-assignable-from T2, then T1 is said to be “strongly” assignable from T2.

    The purpose of this concept is to distinguish cases where it is possible to delimit adjacent objects. This is necessary, for example, when deserializing arrays, to avoid a situation where extra members in an array element could throw off the deserialization of subsequent elements.

    This definition is overly restrictive and can even prevent arrays of non-mutable elements from being assignable to themselves.

    Proposed Resolution:

    Amend the definition to consider any type strongly assignable to itself.

    Proposed Revised Text:

    The definition of the term “strongly assignable” in section 7.2.4, Type Compatibility: “is-assignable-from” relationship, states:

    If types T1 and T2 are both mutable and T1 is-assignable-from T2, then T1 is said to be “strongly” assignable from T2.

    Append the following sentence:

    Any type is also considered (trivially) strongly assignable from itself, regardless of its extensibility kind.

  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Amend the definition of “strongly assignable” to consider any type strongly assignable to itself

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Incorrect default extensibility kind value in XSD file

  • Key: DDSXTY_-12
  • Legacy Issue Number: 16271
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    OMG Issue No: ?????

    Title: Incorrect default extensibility kind value in XSD file

    Source:

    RTI (Mr. Alejandro de Campos, alejandro@rti.com)

    Summary:

    The declaration of the complex type structOrUnionTypeDecl in the XSD file contains the following attribute declaration:

    <xs:attribute name="extensibility"

    type="extensibilityKind"

    use="optional"

    default="false"/>

    However, “false” is not a valid value for the extensibilityKind type.

    Proposed Resolution:

    Change the default value to “extensible”.

    Proposed Revised Text:

    Replace the following attribute declaration within the complex type structOrUnionTypeDecl:

    <xs:attribute name="extensibility"

    type="extensibilityKind"

    use="optional"

    default="false"/>

    …with this one:

    <xs:attribute name="extensibility"

    type="extensibilityKind"

    use="optional"

    default="extensible"/>

  • Reported: DDS-XTypes 1.0b2 — Mon, 23 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Change the default value to “extensible”.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Incorrect union assignability rules

  • Key: DDSXTY_-15
  • Legacy Issue Number: 16366
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The type assignability rules for unions have a number of problems (see the UNION_TYPE row of the table in section 7.2.4.5, Aggregation Types):

    · The second and third bullets in the list of rules are redundant.

    · According to the fourth bullet (assignability of default members), a union with a default label may not even be assignable to itself.

    · The rules do not account for member IDs and names, which can be significant when deserializing objects in some data representations.

    · The rules do not account for the fact that the discriminator may or may not be a key.

    · The rules do not account for extensibility kind.

    · The rules are under-specified with respect to malformed samples. Specifically, the discriminator may select a particular member X of the union, but the implementation may discover in its place a different member Y. (This situation will be detectable only with certain data representations.)

    Proposed Resolution:

    Apply the followin rules:

    · Apply the member ID, name, and type matching rules for structures to unions as well.

    · Every discriminator value in T2 must select the “same” member in T1—or no member at all. This can be checked in three steps:

    1. Every discriminator value in a non-default label of T2 selects the same member in T1 or none at all.

    2. Every discriminator value in a non-default label of T1 selects the same member in T2 or none at all.

    3. If both T1 and T2 have a default label, the corresponding members must be assignable.

    · Either both types must have a key or neither.

    · The extensibility kinds must match.

    · Specify explicitly that an object of a union with a mismatch between its discriminator and non-discriminator members is considered malformed. The impact is unspecified, although implementations may consider the object unassignable.

    Proposed Revised Text:

    Replace the center column of the UNION_TYPE row of the table in section 7.2.4.5, Aggregation Types, with the following:

    UNION_TYPE if and only if it is possible to unambiguously identify the appropriate T1 member based on the T2 discriminator value and to transform both the discriminator and the other member correctly. Specifically:

    · T1.discriminator.id == T2.discriminator.id and T1.discriminator.type is-assignable-from T2.discriminator.type.

    · Either the discriminators of both T1 and T2 are keys or neither are keys.

    · Any members in T1 and T2 that have the same name also have the same ID and any members with the same ID also have the same name.

    · 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.

    · T1.extensibility == T2.extensibility.

    · A discriminator value appearing in a non-default label of T2 selects a member m2. If the same discriminator value selects a member m1 of T1, then m1.id == m2.id.

    · A discriminator value appearing in a non-default label of T1 selects a member m1. If the same discriminator value selects a member m2 of T2, then m1.id == m2.id.

    · If both T1 and T2 have a default label, then the IDs of the members selected by those labels must be equal.

    AND if T1 is final, the number of members in T1 is equal to the number of members in T2.

    Remove the footnote that is linked to the old contents of that table cell.

    Append the following paragraphs to the right-hand column of the same table row:

    If either member of the union is unassignable, then the T2 object is unassignable to T1.

    If the discriminator value of a union object and its non-discriminator member do not agree with one another, the object is considered malformed. In such a case, the behavior is unspecified. In particular, the implementation may or may not be able to detect this error. If it can, it should consider the object unassignable.

  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Apply the following rules:
    • Apply the member ID, name, and type matching rules for structures to unions as well.
    • Every discriminator value in T2 must select the “same” member in T1—or no member at all. This can be checked in three steps:
    1. Every discriminator value in a non-default label of T2 selects the same member in T1 or none at all.
    2. Every discriminator value in a non-default label of T1 selects the same member in T2 or none at all.
    3. If both T1 and T2 have a default label, the corresponding members must be assignable.
    • Either both types must have a key or neither.
    • The extensibility kinds must match.
    • Specify explicitly that an object of a union with a mismatch between its discriminator and non-discriminator members is considered malformed. If an implementation is able to detect this case, it shall consider the object unassignable. If not, then the impact is unspecified.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Inconsistent bit set/integer equivalency

  • Key: DDSXTY_-14
  • Legacy Issue Number: 16365
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    A bit set with bit bound <= 8 is mapped to a byte in some places (page 78 and 40) and to an unsigned short in others (page 88). (Page numbers refer to beta 2.)

    Proposed Resolution:

    A bit set with bit bound <= 8 should be serialized as a single byte.

    Proposed Revised Text:

    In the table in section 7.5.1.2.2, BitSet Types, replace these rows:

    Bit Set Bound
    Unsigned Integer Equivalent

    1–16
    unsigned short

    …with the following:

    Bit Set Bound
    Primitive Equivalent

    1–8
    octet

    9–16
    unsigned short

  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    A bit set with bit bound <= 8 should be serialized as a single byte.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Ambiguous description of serializing discovery types

  • Key: DDSXTY_-13
  • Legacy Issue Number: 16364
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Alejandro Campos)
  • Summary:

    The definition of PID_LIST_END in Table 27 in section 7.4.1.2.1, Interpretation of Parameter ID Values, reads:

    RTPS specifies that the PID value 1 shall be used to terminate parameter lists within the DDS built-in topic data types. Rather than reserving this parameter ID for all types, thereby complicating the member ID-to-parameter ID mapping rules for all producers and consumers of this Data Representation, Simple Discovery types only shall be subject to a special case: member ID 1 shall not be used, and either parameter ID 0x3F02 or parameter ID 1 shall terminate the parameter list.

    The meaning of “Simple Discovery types” is not clear. It should not apply to all mutable types that might ever be used as part of the Simple Discovery process. It is intended only to maintain backward compatibility with types defined in DDS-RTPS.

    Proposed Resolution:

    See the Proposed Revised Text below.

    Proposed Revised Text:

    Append an additional sentence: “These types consist of the built-in topic data types, and those other types that contain them as members, as defined by [RTPS].”

  • Reported: DDS-XTypes 1.0b2 — Tue, 5 Jul 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    See the Revised Text below

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Difficult to apply automation to statically defined types

  • Key: DDSXTY_-9
  • Legacy Issue Number: 16241
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Application code (i.e. business logic) generally depends statically on particular types and their members. Therefore, it is appropriate to define these types statically (e.g. in IDL) and generate code for them in order to take advantage of static type safety and improved performance.

    In contrast, infrastructure code (i.e. logic that is independent of particular applications) generally must not depend on application-specific types, because such dependencies prevent that code from being reused.

    These two kinds of code can exist within a single component. For example:

    · The properties of application-specific types might be checked against a common set of rules to ensure that they meet organizational or program-specific guidelines.

    · Certain design patterns may call for arbitrary application-specific types to be augmented in uniform ways.

    · Type-specific application activities, such as reading and/or writing data, might be logged or recorded.

    The straightforward way to handle these scenarios would be to:

    1. Convert a generated type definition into a DynamicType object.

    2. Convert an object of a generated type into a DynamicData object.

    3. Pass these two dynamic objects to the infrastructure code and allow it to operate on them.

    Unfortunately, the specification does not provide such a capability. Instead, applications have to manually construct DynamicType and DynamicData objects member by member. This code is not only verbose but also brittle, because if the static type definition changes (e.g. during development or across versions), it can grow out of sync with the hand-written code that manipulates that definition.

    Discussion:

    We need three new conversions:

    1. TypeSupport à DynamicType

    2. DynamicData à sample object

    3. Sample object à DynamicData

    These operations could either be added to the TypeSupport interface or to a “type builder” interface. The former approach is preferred, because the generic type parameter of the TypeSupport in the C++ and Java PSMs allows a degree of type safety that way.

    Proposed Resolution:

    Introduce three new TypeSupport operations:

    1. get_type: Get a DynamicType object corresponding to the TypeSupport’s data type.

    2. create_sample: Create a sample of the TypeSupport’s data type from an input DynamicData object. If the DynamicType of the DynamicData is not compatible with the TypeSupport’s data type, raise an error.

    3. create_dynamic_sample: Create a DynamicData object from an input sample of the TypeSupport’s data type.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Introduce three new TypeSupport operations:
    1. get_type: Get a DynamicType object corresponding to the TypeSupport’s data type.
    2. create_sample: Create a sample of the TypeSupport’s data type from an input DynamicData object.
    3. create_dynamic_sample: Create a DynamicData object from an input sample of the TypeSupport’s data type.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Changing a DynamicType object is ambiguous

  • Key: DDSXTY_-8
  • Legacy Issue Number: 16240
  • Status: closed  
  • Source: Brookhaven National Laboratory ( Nikolay Malitsky)
  • Summary:

    The current DynamicType API allows a type definition to be changed. Such a change can be ambiguous at best and dangerous at worst.

    · Suppose that the type already types (DynamicData) objects. Should all of those objects refer to the old version of the type or the new version? If the new version, how shall we address the situation where the new type is inconsistent with the existing data contents?

    · Suppose that the type has already been registered with some domain participant. Does the registered type name refer to the old version of the type or the new version? What shall be done about samples that may already have been published or received using the old version?

    · Can DynamicTypeFactory cache and reuse identical types that are requested more than once? Ideally yes, but the ability to change a type makes the state management necessary to support this behavior very complicated.

    It would be safer, clearer, and more efficient if DynamicType objects were immutable once created. That implies that either the factory must take sufficient inputs to fully create a type in one step, or we must employ a builder or similar pattern.

    Discussion:

    A builder pattern would give the application more flexibility in how to create new types. It would also nicely encompass the current load_type operations as well as hypothetical PSM-specific operations, such the creation of a DynamicType from a Java Class object.

    Proposed Resolution:

    TO DO

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Define a new class DynamicTypeBuilder as a copy of the current definition of DynamicType. Remove from DynamicType all operations that modify an object, and add to DynamicTypeBuilder an operation build that returns a corresponding (immutable) DynamicType.
    Update the existing DynamicTypeFactory to create instances of DynamicTypeBuilder instead of DynamicType. Rename this class DynamicTypeBuilderFactory accordingly.
    Replace the existing operation DynamicType::clone with a corresponding create operation in DynamicTypeBuilderFactory.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Optional, must_understand members of non-mutable aggregation types cannot be accurately represented in CDR

  • Key: DDSXTY_-11
  • Legacy Issue Number: 16243
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Members of a structure or union type have a small number of metadata attributes, among them:

    · optional: indicates that the member may or may not take a value in a particular sample

    · must_understand: indicates that a consumer of the data must discard the sample if it encounters such a field in it

    The type-level assignability rules detect mismatches respecting non-optional must_understand members. (Such members will always take a value, and therefore there is no possibility of data exchange between the producer and consumer.) However, must_understand members that are optional must be detected on a sample-by-sample basis: any sample that does not contain the offending member can be exchanged, but those that do cannot.

    The XML Data Representation allows the encoding of the must_understand attribute within each sample, as does the parameterized encapsulation variants of the Extended CDR Data Representation. However, the traditional, non-parameterized encapsulation variants—used by final and extensible structures and unions—do not permit this attribute to be expressed. As a result, consumers will not be able to detect when it should have been present, and may therefore present incorrect data to applications.

    Discussion:

    The traditional CDR encapsulations prefix each optional member with a 32-bit “header” that indicates the presence and size of the member. In contrast, the parameterized CDR encapsulations prefix each member with a 32-bit parameter header that indicates the presence, size, ID, and metadata flags of the member, including must_understand. Therefore, we can reuse the parameter header structure we already have to solve this problem, instead of using just a 32-bit size, with no increase in overhead.

    Proposed Resolution:

    Reorganize the Extended CDR Data Representation section such that it first defines the parameter header structure and the member-ID-to-parameter-ID mapping. Second it shall define the traditional encapsulation variants, and finally it shall define the (fully) parameterized encapsulation variants.

    Within the middle section—traditional CDR—update section 7.4.1.1.5.2, “Optional Members.” Remove the description of a 32-bit size, and in its place describe the use of a parameter header. Note that either the four-byte header defined by DDS-RTPS or the 12-byte extended header defined by DDS-XTypes may be used.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Update section 7.4.1.1.5.2, “Optional Members.” Instead of preceding each optional member with a 32-bit size, use a parameter header. Note that either the four-byte header defined by DDS-RTPS or the 12-byte extended header defined by DDS-XTypes may be used.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

New QoS policies don’t indicate whether they can be changed

  • Key: DDSXTY_-10
  • Legacy Issue Number: 16242
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Source:

    RTI (Mr. Alejandro de Campos, alejandro@rti.com)

    Summary:

    Each DDS QoS policy must define a couple of attributes: whether or not the policy has request-offer (RxO) semantics and whether or not it can be changed after an entity is enabled. The two new QoS policies defined by DDS-XTypes—TypeConsistencyEnforcementQosPolicy and DataRepresentationQosPolicy—define the first part but not the second.

    Discussion:

    Because of their potential interactions with historical data, neither of these policies should be changeable after an entity is enabled.

    Proposed Resolution:

    State in the introduction to each policy that its value cannot be changed after an entity is enabled.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    State in the introduction to each policy that its value cannot be changed after an entity is enabled

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Typographical errors

  • Key: DDSXTY_-7
  • Legacy Issue Number: 16239
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification contains the following identified typographical errors:

    · The third bullet in section 2.2, “Network Interoperability Conformance”, which begins with “Data Representation…”, is lacking an opening parenthesis at the start of the second sentence. The closing parenthesis is already present.

    Proposed Resolution:

    See the trivial corrections described above.

    Proposed Revised Text:

    See the trivial corrections described above

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    See the trivial corrections described above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Type signature fields in built-in topic data shouldn't use unbounded strings

  • Key: DDSXTY_-6
  • Legacy Issue Number: 16238
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The type_name members of TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData are bounded at 256 characters. The equivalent_type_name and base_type_name members store sequences of type names, but the strings in those sequences are unbounded. The flexibility to store strings of any length is unnecessary, because no string can appear there that doesn’t also appear in a type_name somewhere, and is therefore of 256 characters or less.

    This issue is minor in that it does not impact correctness. However, it does impact clarity to a small extent and can impact the efficiency of some implementations.

    Proposed Resolution:

    Define a typedef “TypeName”, a string bounded at 256 characters. (See also issue #15969.)

    Define a typedef “TypeNameSeq”, an unbounded sequence of TypeName elements.

    Change the type of the equivalent_type_name and base_type_name members from StringSeq to TypeNameSeq.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    This issue is obsolete in the face of issue #16561: the resolution of that issue eliminates the type signature concept altogether. Therefore, this issue should be merged with that one.
    Disposition: Merged with issue #16561

  • Updated: Fri, 6 Mar 2015 21:48 GMT

No way to get or set length of collection-typed DynamicData objects

  • Key: DDSXTY_-5
  • Legacy Issue Number: 16237
  • Status: closed  
  • Source: Brookhaven National Laboratory ( Nikolay Malitsky)
  • Summary:

    A DynamicData object may encapsulate the state of an object of a collection type—a sequence, array, string, or map. In such a case, it is necessary to be able to get and set the length of the collection.

    Discussion:

    We need to add an accessor for the current length. This accessor can also be useful for other object of other types; for example, it can return the number of members in a structure.

    However, it is not appropriate to add a mutator for the length directly:

    · If the length of a collection is increased, that implies the addition of new elements. But the values of these new elements will not be meaningful.

    · If the length of a collection is decreased, that implies the removal of existing elements. But that may not be meaningful (what does it mean to remove a non-optional member of a structure?) of useful (why would you want to clear the fifth element of a bit set just because of what its index is?).

    · The lengths of some types cannot legally be changed at all—for example, array types.

    Therefore, it is better to allow elements to be added and removed, where appropriate, and thereby modify the length implicitly.

    Proposed Resolution:

    Add an operation get_length to the DynamicData class.

    · If the object is of a collection type, return the number of elements currently in the collection. In the case of an array type, this value will always be equal to the bound.

    · If the object is of a bit set type, return the number of named flags that are currently set in the bit set.

    · If the object is of a structure or annotation type, return the number of members in the object. This value may be different than the number of members in the corresponding DynamicType—for example, some optional members may be omitted; see the existing DynamicData documentation.

    · If the object is of a union type, return the number of members in the object. This value will always be two: the discriminator and the current member corresponding to it.

    · If the object is of a primitive or enumeration type, it is atomic: return one.

    · If the object is of an alias type, return the value appropriate for the alias’s base type.

    Expand the contracts of the existing set_<type>_value operations to allow them to append new elements to resizable collections—strings, sequences, and maps. (This behavior is aligned with the existing contract of the clear operations, which states that cleared elements of resizable collections shall be removed.) Obtain the member ID associated with the new value as follows:

    · For a string or sequence type, use get_member_id_at_index to obtain an ID for the index one greater than the current length.

    · For a map type, use get_member_id_by_name to obtain an ID for the new map key.

    Proposed Revised Text:

    TO DO

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Add an operation get_item_count to the DynamicData class.
    • If the object is of a collection type, return the number of elements currently in the collection. In the case of an array type, this value will always be equal to the product of the bounds of all array dimensions.
    • If the object is of a bit set type, return the number of named flags that are currently set in the bit set.
    • If the object is of a structure or annotation type, return the number of members in the object. This value may be different than the number of members in the corresponding DynamicType—for example, some optional members may be omitted; see the existing DynamicData documentation.
    • If the object is of a union type, return the number of members in the object. This value will always be two: the discriminator and the current member corresponding to it.
    • If the object is of a primitive or enumeration type, it is atomic: return one.
    • If the object is of an alias type, return the value appropriate for the alias’s base type.
    Expand the contracts of the existing set_<type>_value operations to allow them to append new elements to resizable collections—strings, sequences, and maps. (This behavior is aligned with the existing contract of the clear operations, which states that cleared elements of resizable collections shall be removed.) Obtain the member ID associated with the new value as follows:
    • For a string or sequence type, use get_member_id_at_index to obtain an ID for the index one greater than the current length.
    • For a map type, use get_member_id_by_name to obtain an ID for the new map key.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Annex D (“DDS Built-in Topic Data Types”) is out of sync with IDL file

  • Key: DDSXTY_-4
  • Legacy Issue Number: 16236
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The equivalent_type_name and base_type_name fields from TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData are described in the prose of the specification and are reflected in the IDL file. However, they missing from the annex; they need to be added.

  • Reported: DDS-XTypes 1.0b2 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    • Replace all literal-formatted text in Annex A (beginning with “<?xml…”) with the contents of the XSD file accompanying the specification.
    • Replace all literal-formatted text in Annex B (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex C (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex D (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex E (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
    • Replace all literal-formatted text in Annex F (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

C++ mapping MAP type needs member access semantics specification

  • Key: DDSXTY_-3
  • Legacy Issue Number: 15981
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The C++ mapping for the new MAP type needs a precise specification of member (or key) access semantics and memory management rules like the CORBA C++ mapping describes for the SEQUENCE type on pages 36-42 (par. 4.15) of the C++ language mapping, version 1.2, formal/2008-01-09.

  • Reported: DDS-XTypes 1.0b2 — Mon, 24 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    Close this issue without making any change.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Restrictions on MAP key element type not (clearly) documented/specified

  • Key: DDSXTY_-2
  • Legacy Issue Number: 15976
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    Allthough the specification of the MAP_TYPE in paragraph 7.2.2.3.4 refers to restrictions for key element type this is not formalized in either the specification for the IDL representation for maps or the C++ language mapping.

    It should be clearly noted (for the IDL representation in bnf) that the key element type is restricted to integer and string types only.

    The current IDL representation specs for map leave all options open for defining the key element type.
    Although the specs in paragraph 7.2.2.3.4 describe the use of other element types as 'behaviour undefined' this is not clear enough as the chosen C++ representation simply will not work when f.i STRUCT or UNION types are chosen as key element type.

  • Reported: DDS-XTypes 1.0b2 — Fri, 21 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    In section 7.2.2.3.4, provide a rationale for the restriction on key types.
    In the section on the Plain Language Binding for map types (7.5.1.3), clarify that the use of an unsupported key element type shall result in a compilation error. Further indicate that in C++ (section 7.5.1.3.1), the Compare function implementation shall consider the character contents of strings; it shall not compare pointer values.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Anonymous types should not be used in IDL examples and the TypeObject representation IDL

  • Key: DDSXTY_-1
  • Legacy Issue Number: 15969
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    IDL Anonymous type declarations should not be used in IDL examples and the 'dds_xtypes.idl' file as this form of type declaration has been deprecated by the latest CORBA specs and will cause compatibility problems with modern CORBA IDL compilers.

  • Reported: DDS-XTypes 1.0b2 — Tue, 18 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0
  • Disposition Summary:

    • In the definitions of GroupDataQosPolicy, TopicDataQosPolicy, and UserDataQosPolicy, replace sequence<octet> with ByteSeq. This change removes occurrences of an anonymous type inherited from DDS itself.
    • In the definitions of TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData, replace the type of the name, topic_name, and type_name fields (string<256>) with the existing typedef ObjectName. This change removes occurrences of an anonymous type inherited from DDS itself.
    • In the definitions of Bytes and KeyedBytes, replace sequence<octet> with ByteSeq.
    • Introduce two typedefs: “VerbatimLanguage” and “VerbatimPlacement”, the first a string bounded at 32 characters and the second at 128 characters. Change the type of the member Verbatim::language to VerbatimLanguage and the type of Verbatim::placement to VerbatimPlacement.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Different applications in the same domain may associate the same Topic with different types

  • Key: DDSXTY-29
  • Legacy Issue Number: 16097
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    Based on the DDS-XTypes specification, different applications in the same domain may associate the same Topic with different types. As a result through discovery it should be possible to find all such definitions. However this is not currently possible with the DDS v1.2 specification and the DDS-XTypes does not provide an extension for this API.

  • Reported: DDS-XTypes 1.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    The following resolution is related to the resolutions of issues #15702, #16007, and #16720.
    Abstract Model:
    A given topic is associated with one or more types. (This is a “topic” in the “virtual” system-wide sense independent of the way a topic is reflected through the API to any given component.) A given writer or reader endpoint is associated with one of the types of its topic.
    If a writer and a reader share the same topic, then it is assumed that they are intended to communicate with one another. At that point, the two endpoints are evaluated to make sure that they are type-compatible—see the resolution to issue #15702.
    On the Network:
    The Topic, Publication, and Subscription built-in topic data types already contain a type_name member. In addition, these data types shall contain a list of type definitions encapsulated in a TypeObject (defined in the resolution to issue #15702). In the Publication and Subscription cases, this “list” shall consist of only a single element. In the Topic case, it may consist of multiple elements.
    There is a related issue that will be addressed in the context of this issue, because it will improve matching performance and prepare the specification for the possibility of future support for polymorphic readers and writers: Today, the TypeObject type representation is not amenable to compact representation or fast comparison: types are identified by a “type ID” that an implementation can generate any way that it wishes. This approach has two weaknesses: (1) A definition is not self-contained—it requires a full tree of the types it uses to also be present. Also, (2) two types may be logically “equal” but may not have the same binary representation, because they refer to the “same” types by different indexes. Therefore, modify the TypeObject representation to replace ad hoc type indexes with deterministic hashes. (The lower-order 64-bits of an MD5 hash of the TypeObject representation of the type is sufficient: a system would require 1e6 types before it would have a 1e-6 probability of a collision. A full 128-bit hash could be used, but the overhead would be significant when data sample sizes are very small.) This change will address both of the above issues. It will also allow implementations to flexibly truncate the amount of detail they put on the network. The overhead can be further reduced if we assume that most members will be of primitive type—we can define a type ID as a union of a (small) primitive type ID and a (hashed, big) complex type ID.
    In the Application Code:
    As always, a Topic object is not the real virtual topic—it is only a local proxy. We retain the constraint that a single local Topic object is associated with only a single type. This constraint keeps the programming model the same for both XTypes-supporting and non-XTypes-supporting implementations, and it keeps the mental model simple for the majority of applications, which will not be aware of the presence of multiple types in their topics.
    To allow endpoints of the same virtual topic to be associated with different types, we make one change: The names of local Topic objects do not need to be unique within a given DomainParticipant, provided that all of those Topics of the same name really represent different slices of the same virtual topic—in other words, they must all have the same name.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS-XTypes @Key annotation Issue

  • Key: DDSXTY-28
  • Legacy Issue Number: 16007
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The @key annotation is currently defined as:

    @Annotation
    local interface Key

    { attribute boolean value default true; }

    ;

    Now suppose I have the following topic type:

    struct ATopicType

    { string a; @Key @ID(20) long b; long c; @Key @ID(10) }

    ;

    What is the key (a,b) or (b,a)? What if there were no annotations?

    The order of the key should be formally defined by the spec as this has an impact, among other things, on the computation of the keyhash.

    The rule could be as simple as taking the key element in the same order of the attribute ID. The other option is to extend the key to support a value, yet I think the first alternative is more orthogonal.

  • Reported: DDS-XTypes 1.0b1 — Wed, 2 Feb 2011 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    The key hash is currently calculated in the following way, according to the DDS-RTPS specification:
    1. Serialize the key members…
    a. …in their declaration order
    b. …in big-endian CDR format
    2. If the serialization is less than or equal to 128 bits, that is the key hash.
    3. Otherwise, apply an MD5 hash to reduce the result to 128 bits.
    Update step (1a) above such that key fields are always serialized in ascending order by member ID rather than by declaration order. Note that this change applies only when calculating the key hash, not at any other time.
    This change is backwards compatible with pre-XTypes DDS implementations, because legacy type definitions will lack @ID annotations, and hence all members will always be in ascending ID order.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can’t initialize TypeId from TypeKind

  • Key: DDSXTY-8
  • Legacy Issue Number: 15688
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    In the IDL definitions for the specification section Representing Types with TypeObject, the type TypeKind is declared to be an enumeration. The type TypeId is declared to be a typedef to long. Certain well-known TypeId values are initialized using TypeKind values. However, this causes compilation errors from some IDL compilers, which do not allow enumerated values to be assigned to integral constants.
    Resolution:
    Change TypeKind from an enumeration to a typedef to short.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Identifiers TypeId and Module collide with IDL keywords

  • Key: DDSXTY-9
  • Legacy Issue Number: 15689
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    In the IDL definitions for the specification section Representing Types with TypeObject:
    • The type “TypeId” collides with the IDL keyword “typeid.”
    • The type “Module” and its member “module” collide with the IDL keyword “module.”
    These collisions cause IDL compilation errors.
    Resolution:
    Escape the identifiers TypeId and Module by preceding them with underscores. Per the IDL specification, this lexical change does not impact the generated code.
    Rename the type member “module” to “mod” to prevent collisions either with the IDL keyword or with the name of the enclosing type.
    Revised Text:
    Replace the type identifier “TypeId” in the IDL file with “_TypeId” everywhere it occurs.
    Replace the type identifier “Module” in the IDL file with “_Module” everywhere it occurs.
    Replace the member identifier “module” (in the type “Module”) in the IDL file with “mod.”

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Don’t require CORBA namespace for primitive types in Plain Language Binding

  • Key: DDSXTY-23
  • Legacy Issue Number: 15703
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The Plain Language Binding relies on the IDL-to-C and IDL-to-C++ language mappings to generate programming APIs for these languages. Unfortunately, these mappings prefix all primitive type names with “CORBA,” which is incorrect and confusing for DDS users. For example:
    • DDS Int32 will become CORBA_Long in C.
    • DDS Float64 will become CORBA::Double in C++.
    Resolution:
    Update the Plain Language Binding for primitive types in C and C++ to place them in a conceptual “DDS” module instead of the current “CORBA” module. At the same time, rename them to be consistent with their names in the DDS type system—for example, “Int32” instead of “Long.” (The Plain Language Binding already makes several extensions to the IDL-to-C/C++ mapping specifications. This change would constitute one more.)
    These new primitive types must be compatible in size and representationwith the definitions in the Type System; these definitions will be provided in a table within the Plain Language Binding section. (As a side effect, they will also be compatible with to their CORBA-module counterparts, such that applications using both DDS and CORBA can assign from one to the other without type casts or loss of information.)

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Update the Plain Language Binding for primitive types in C and C++ to place
    them in a conceptual “DDS” module instead of the current “CORBA” module. At
    the same time, rename them to be consistent with their names in the DDS type
    system—for example, “Int32” instead of “Long.” (The Plain Language Binding
    already makes several extensions to the IDL-to-C/C++ mapping specifications.
    This change would constitute one more.)
    These new primitive types must be compatible with the definitions in the Type
    System; these definitions will be provided in a table within the Plain Language
    Binding section. (As a side effect, they will also be compatible with their CORBAmodule
    counterparts, such that applications using both DDS and CORBA can
    assign from one to the other without type casts or loss of information.)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allow more flexible type consistency enforcement

  • Key: DDSXTY-22
  • Legacy Issue Number: 15702
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Summary:
    Section 7.6.1.3.1, TypeConsistencyEnforcementQosPolicy: Conceptual Model, identifies the type consistency enforcement kinds. This QoS policy is request-offer (RxO); readers and writers must match exactly in order to communicate. However, this requirement for an exact match is not required by implementations and is too restrictive for users.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    The resolution below is closely related to the resolutions of issues #16097 and #16561.
    The existing type consistency enforcement QoS policy, which governs both type signature consistency and type definition structural consistency, shall be simplified. It shall be removed from the Topic and DataWriter QoS and the corresponding built-in topic data types. It shall remain in the DataReader QoS and in the Subscription built-in topic data type. Its “kind” enumeration shall have the following values:
    • DISALLOW_TYPE_COERCION: The DataWriter and the DataReader must support the same data type in order for them to communicate.
    • ALLOW_TYPE_COERCION: The DataWriter and the DataReader need not support the same data type(s) in order for them to communicate as long as the reader’s type is assignable from the writer’s type.
    The default settings shall be as follows:
    • For compliant readers: ALLOW_TYPE_COERCION
    • Inferred for non-compliant readers: DISALLOW_TYPE_COERCION
    Type compatibility shall be determined according to the following steps:s
    1. The TypeObject type definition is considered first, provided that it is available for both the Publication and the Subscription. (This is anticipated to be the most common case for DDS-XTypes-conformant implementations.) If the Subscription allows type coercion, then its type must be assignable from the type of the Publication. If the Subscription does not allow type coercion, then its type must be equal to that of the Publication.
    2. If either the Publication or the Subscription does not provide any TypeObject definitions, then the type names are consulted. (This case is important in cases where a given component cannot, or does not wish to, provide concrete type definitions. For example, it may not support XTypes, it may wish to conserve bandwidth, it may not wish to reveal its type definition(s), or it may not even be type-aware—it may simply record binary payloads, for example.) The Subscription and Publication type_name fields must match exactly.
    If the reader and writer are not type-compatible, the middleware raises an INCONSISTENT_TOPIC status change.
    The following behaviors will result from the default values and evaluation orders above when writers and readers have default QoS:
    • Compliant writers will communicate with compliant readers. The reader will allow type coercion. This behavior is what we want, and it is unchanged from the current DDS-XTypes default.
    • Compliant writers will communicate with non-compliant readers. The reader will not allow type coercion, so the types (really the type names) must match exactly. This behavior is unchanged from the implied contract of DDS implementations prior to DDS-XTypes.
    (Suppose the writer has out-of-band knowledge of the reader’s type definition. If the writer determines that the types are not equal, it will consider the topic inconsistent and forbid communication. The reader will be unable to detect this inconsistency. However, the reader will not receive any data from the writer, so deserialization errors will be prevented just the same.)
    • Non-compliant writers will communicate with compliant readers. The reader will allow type coercion. This behavior provides maximum flexibility without requiring changes to deployed non-compliant applications.
    (Suppose the reader has out-of-band knowledge of the writer’s type definition. If the reader determines that the types are not assignable, the writer will be unable to detect this inconsistency and may send data to the reader nonetheless. The reader implementation will need to detect and eliminate this extraneous data without attempting to deserialize it—for example, by checking upon receiving the data from the socket whether the source data is actually from a matched writer. This edge case is little different from other preexisting cases, such as the use by a non-matching writer of a multicast address used by the reader. Therefore, it is not expected to be a barrier to implementation.)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical errors

  • Key: DDSXTY-21
  • Legacy Issue Number: 15701
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification contains the following typographical errors:
    • Section 7.6.1.3.1, TypeConsistencyEnforcementQosPolicy: Conceptual Model, bullet EXACT_NAME: “…they’re structural definitions…” should be “…their structural definitions….”
    Resolution:
    Fix the errors as described above.
    Revised Text:
    Revisions are described in the summary above

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Fix the errors as described above.
    Note that the typo is section 7.6.1.3.1 will be addressed automatically by the resolution to issue #15702, which replaces the text is question. If no further typos are added to this issue, it can be closed as a duplicate of that issue.
    Revised Text:
    Revisions are described in the summary above.
    Disposition: Merged with issue 15702

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mutable structures with an empty intersection should not be considered assignable

  • Key: DDSXTY-20
  • Legacy Issue Number: 15700
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The type assignability rules for structure types (section 7.2.4.5, Aggregation Types) allow mutable types to be assigned in either direction, so long as there are no name, ID, or type conflicts among the types’ members. Unfortunately, these rules permit a degenerate case: two mutable types having no key members and no members in common will have no conflicts, and therefore will be considered assignable. However, readers will always observe every sample to have all default/empty contents.
    Resolution:
    Add an additional rule to the assignability determination to require that at least one member is in common.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add an additional rule to the assignability determination to require that at least
    one member is in common.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML representations should define namespaces

  • Key: DDSXTY-19
  • Legacy Issue Number: 15699
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Currently, the XML Type Representation and XML Data Representation do not define XML namespaces. This omission prevents XML documents of these types from being used in certain contexts, such as within XML catalogs or SOAP messages.
    Resolution:
    1. Specify the XML namespace for the XML Type Representation. This namespace shall be formed by appending the OMG document number of the specification to the OMG HTTP domain in the following way: http://www.omg.org/<TF or TC>/<year>/<month>/<document ordinal>/<section_name>. For example, the namespace for the beta 1 specification would be: http://www.omg.org/ptc/2010/05/12/XML_Type_Representation.
    2. Allow the association of a target namespace with the XSD Type Representation of a set of types, such that documents conforming to such type definitions may be properly validated against that namespace. This target namespace will be implied by the fully qualified name of each non-nested type, such that all DDS types, regardless of which Type Representation was used to define them, implicitly define a target namespace that can be used to validate XML Data Representation documentsThis mechanism will be specific to the XSD Type Representation; the concept of a target XML namespace will not be promoted into the Type System (or, by extension, into other Type Representations). (This implied target namespace will be a URN, not a URL; it will not be possible to dereference it.)
    2.3. Allow applications the choice of whether to include XML namespaces on the network. Split the XML Data Representation into two dialects: XML_VALID and XML_WELL_FORMED. The former will include explicit namespace declarations and properly qualify all element and attribute names. The latter will, for the sake of compactness, omit namespace information.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    1. Specify the XML namespace for the XML Type Representation. This
    namespace shall be formed by appending the OMG document number of the
    specification to the OMG HTTP domain in the following way:
    http://www.omg.org/<TF or TC>/<year>/<month>/<document
    ordinal>/<section_name>. For example, the namespace for the beta 1
    specification would be:
    http://www.omg.org/ptc/2010/05/12/XML_Type_Representation.
    2. Allow the association of a target namespace with the XSD Type
    Representation of a set of types, such that documents conforming to such
    type definitions may be properly validated against that namespace. If this
    target namespace is not specified explicitly, it shall be implied by the fully
    qualified name of each module, such that all DDS types, regardless of which
    Type Representation was used to define them, implicitly define a target
    namespace that can be used to validate XML Data Representation
    documents. The implied namespace shall take the form
    ddstype://www.omg.org/<module path>, where <module path> is a
    list of enclosing modules, separated by forward slashes, from outermost to
    innermost. (Note that this implied target namespace is a URN, not a URL; it
    will not be possible to dereference it.)
    3. Allow applications the choice of whether to include XML namespaces on the
    network. Split the XML Data Representation into two dialects: “valid” and “well
    formed.” The former will include explicit namespace declarations and properly
    qualify all element and attribute names. The latter will, for the sake of
    compactness, omit namespace information.
    With respect to (#2), the ability of an XSD author to explicitly specify a target
    namespace—rather than relying on a module-based implied namespace—is
    important to retain compatibility with the CORBA to WSDL/SOAP Interworking
    Specification, on which the XSD Type Representation depends. The authors of
    that specification explicitly chose not to support module-based namespaces for
    performance reasons, as described in section 4.1.4 of that specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide minimal backwards-compatible conformance point

  • Key: DDSXTY-25
  • Legacy Issue Number: 15705
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    One of the reasons for the development of the DDS-XTypes specification was the prior lack of explicitness and formality in the DDS type system and in its representations. DDS-XTypes addresses this need—and simultaneously extends both the type system and its representations. It would help the discourse about DDS systems, and the modeling of DDS systems, if a subset of DDS-XTypes were defined that identified only those parts of DDS and/or DDS-RTPS that were in broad use before the existence of DDS-XTypes.
    This subset would include the following:
    • A subset of the Type System:
    o The full set of primitive types
    o Strings of narrow or wide characters
    o Sequences
    o Aliases
    o Structures without inheritance and with “final” extensibility
    o Enumerations
    o Unions
    • The IDL Type Representation of the above
    • The CDR Data Representation of the above
    • The Plain Language Binding for the above

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Identify the above subset of the specification in a new, non-normative, annex

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide formal grammar for new IDL Type Representation constructs

  • Key: DDSXTY-24
  • Legacy Issue Number: 15704
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL Type Representation defines syntax for Type System concepts that were previously not expressible in IDL, such as annotations, maps, etc. This syntax is currently defined in prose and with examples. The specification should additionally provide a formal EBNF grammar.
    Resolution:
    Add EBNF grammar constructs to the relevant sections of the specification document.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add EBNF grammar productions to the relevant sections of the specification document.
    To avoid whitespace sensitivity in these productions, modify the Alternative (comment-like) Syntax when multiple annotations are applied. Instead of writing this:
    //@MyFirstAnnotation @MySecondAnnotation
    …write this:
    //@MyFirstAnnotation //@MySecondAnnotation

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improve support for shared data

  • Key: DDSXTY-27
  • Legacy Issue Number: 15707
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The Type System currently allows a type designer to specify that the storage for a type member may be located outside of the type itself. (This is an important capability when, for example, objects of the member’s type are very large.) However, it provides insufficient flexibility when such objects are stored in collections: the entire collection may be stored externally, but the collection members must be stored contiguously.
    Resolution:
    Enhance the Type System to allow collection elements to be shared, not just members of aggregation types. In the IDL Type Representation, this shall be expressed syntactically by the application of the built-in @Shared annotation to the collection member type.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Enhance the Type System to allow collection elements to be shared, not just members of aggregation types. In the IDL Type Representation, this shall be expressed syntactically by the application of the built-in @Shared annotation to the collection member type.
    Note that this resolution does not provide a general-purpose annotation facility for collection members. It merely provides an appropriate Type System property and Type Representation syntax to express it.
    Sequences:
    sequence<@Shared Foo, 42> sequence_of_foo;
    // or:
    sequence<
    Foo, //@Shared
    42
    > sequence_of_foo;
    Arrays:
    Foo array_of_foo @Shared [42];
    // or:
    Foo array_of_foo //@Shared
    [42];
    Maps:
    map<string, @Shared Foo, 42> map_of_string_to_foo;
    // or:
    map<
    string,
    Foo, //@Shared
    42
    > map_of_string_to_foo;
    Strings: Strings will not support this feature (i.e. individual characters cannot be stored externally to the string itself). Since string elements can only be individual narrow or wide characters, this “limitation” in theory is not expected to be a limitation in practice.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reduce size of DynamicData API

  • Key: DDSXTY-26
  • Legacy Issue Number: 15706
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The DynamicData class, part of the Dynamic Language Binding, has a huge API consisting of many dozens of methods. This large size makes the API harder to understand and reuse.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Change the design of the class to reduce the size of the API. Specifically:
    • Replace navigation by name, ID, or index with navigation by ID only. Provide conversion methods to obtain the ID based on either of the other two. When the object is of some type for which the concept of “member ID” is not applicable (e.g. sequences), the user can nevertheless convert from the index to a “member ID” and look up based on that. It is not necessary to specify the mapping from index to ID in such cases; all that matters is that the implementation can provide one. (Where the range of indexes and IDs overlap, the “mapping” could even be a no-op.)
    • Coalesce access to sequences and arrays.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect FooDataWriter overloads for built-in types

  • Key: DDSXTY-16
  • Legacy Issue Number: 15696
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL file contains specializations of all of the type-specific interfaces for the new built-in types: “Foo”DataWriter and “Foo”DataReader. Some of these specializations contain additional “overloads” of DDS-standard types-specific methods for the sake of convenience. However, some of these overloads are not correct:
    • KeyedStringDataWriter::unregister_instance_w_key does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance method specified by DDS.)
    • KeyedStringDataWriter::unregister_instance_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance_w_timestamp method specified by DDS.)
    • KeyedStringDataWriter::dispose_w_key does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose method specified by DDS.)
    • KeyedStringDataWriter::dispose_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose_w_timestamp method specified by DDS.)
    • BytesDataWriter::write_string_w_bytes should be named BytesDataWriter::write_w_bytes (copy-paste error).
    • BytesDataWriter::write_string_w_bytes_w_timestamp should be named BytesDataWriter::write_w_bytes_w_timestamp (copy-paste error).
    • KeyedBytesDataWriter::unregister_instance_w_key does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance method specified by DDS.)
    • KeyedBytesDataWriter::unregister_instance_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance_w_timestamp method specified by DDS.)
    • KeyedBytesDataWriter::write_bytes_w_key doesn’t actually include the key among its arguments. It should.
    • KeyedBytesDataWriter::write_bytes_w_key_w_timestamp doesn’t actually include the key among its arguments. It should.
    • KeyedBytesDataWriter::dispose_w_key does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose method specified by DDS.)
    • KeyedBytesDataWriter::dispose_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose_w_timestamp method specified by DDS.)
    Resolution:
    Correct the method signatures as described in the summary above.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Correct the method signatures as described in the summary above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing definitions of TypeSupport specializations for built-in types

  • Key: DDSXTY-15
  • Legacy Issue Number: 15695
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL file contains specializations of all of the type-specific interfaces for the new built-in types: “Foo”DataWriter and “Foo”DataReader. However, the FooTypeSupport definitions are not included. These specializations require no method overloads; however, they should be included for the sake of clarity and completeness.
    Resolution:
    Add the missing type definitions.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add the missing type definitions

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allow IDL compatibility pragma declarations to nest

  • Key: DDSXTY-18
  • Legacy Issue Number: 15698
  • Status: closed  
  • Source: Jackrabbit Consulting ( Dr. Robert (Nick) Stavros)
  • Summary:

    Section 7.3.1.1.2, Forward Compatibility with Respect to Compilers, defines a pragma declaration that IDL file authors can use to delimit portions of their IDL files that require certain versions of this specification. Especially since IDL files can include one another, it would be helpful if such pragma declarations were allowed to nest within one another.
    Resolution:
    Allow pragma declarations to nest.
    • Any version number specified by a nested pragma overrides the enclosing version number, if any.
    • Any unclosed declaration shall be considered to continue until the end of the input.
    In addition, the pragma “end” declaration shall—like the “begin” declaration—allow a version number to be specified to clarify the nesting relationship.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Allow pragma declarations to nest.
    • Any version number specified by a nested pragma overrides the
    enclosing version number, if any.
    • Any unclosed declaration shall be considered to continue until the end of
    the input.
    In addition, the pragma “end” declaration shall—like the “begin” declaration—
    allow a version number to be specified to clarify the nesting relationship.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consolidate IDL built-in annotations in machine-readable file

  • Key: DDSXTY-17
  • Legacy Issue Number: 15697
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification provides equivalent definitions for the built-in annotations defined by the IDL Type Representations. However, it only includes these in the specification document, not in the IDL file.
    Resolution:
    Add these definitions to the IDL file. Add this content as an additional annex in the specification document.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add these definitions to the IDL file. Add this content as an additional annex in
    the specification document

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Updated QoS definitions should be provided

  • Key: DDSXTY-14
  • Legacy Issue Number: 15694
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The specification dictates that the new QoS policies DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy apply to Topics, DataReaders, and DataWriters. These additions are reflected in the IDL file by the inclusion of corresponding members in the built-in topic data types TopicBuiltinTopicData, SubscriptionBuiltinTopicData, and PublicationBuiltinTopicData. Corresponding additions to TopicQos, DataReaderQos, and DataWriterQos are therefore implied, but updated definitions of those types are not provided in the IDL file.
    Resolution:
    Add the missing type definitions to the IDL file.
    The type extensibility kinds of the QoS structures should be MUTABLE to be consistent with the built-in topic data types, which are also containers of QoS policies and which have that extensibility kind.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add the missing type definitions to the IDL file.
    The type extensibility kinds of the QoS structures should be MUTABLE to be
    consistent with the built-in topic data types, which are also containers of QoS
    policies and which have that extensibility kind.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extensibility kinds of new QoS policies are not specified in a consistent way

  • Key: DDSXTY-13
  • Legacy Issue Number: 15693
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL file augments the DDS-standard QoS policies with meta-data defined by this specification in a way that is consistent with the serialization of those policies as defined by the DDS-RTPS specification. Specifically, it defines each policy to be “nested” (meaning that it is intended to be propagated only when contained within another type) to have an extensibility kind of EXTENSIBLE (meaning that members can be appended to the end of the type, but that members cannot be inserted in the middle or reordered).
    In contrast, the two new QoS policies introduced by the specification—DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy—are defined to be nested, but their extensibility kinds are not specified. Per this specification, the kind EXTENSIBLE will be inferred by default but could be overridden by implementations. In order to be clear and avoid potential interoperability problems, these types should explicitly specify the extensibility kind EXTENSIBLE, just as all other policies do.
    Resolution:
    Add the built-in annotation @Extensibility(EXTENSIBLE_EXTENSIBILITY) to the definitions of DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy in the IDL file.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add the built-in annotation @Extensibility(EXTENSIBLE_EXTENSIBILITY)
    to the definitions of DataRepresentationQosPolicy and
    TypeConsistencyEnforcementQosPolicy in the IDL file.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unclear member names when programming language doesn’t support typedef

  • Key: DDSXTY-11
  • Legacy Issue Number: 15691
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    Summary:
    In the IDL definitions for the specification section Representing Types with TypeObject, some members of type MemberId are named simply member, and some members of type TypeId are named simply type. The fact that the integral types of these members represent IDs is clear to readers of the IDL or to readers of generated code in languages that support typedef (such as C), because the type name is explicit. However, in Java and other programming languages that do not support typedef, the types of these members degrades to simply int (or another built-in integral type). This type obscures the meanings of the members.
    Resolution:
    Name the members in question more explicitly: member_id and type_id.
    Revised Text:
    Rename the following type members in the IDL file:
    • AnnotationUsageMember::member ? AnnotationUsageMember::member_id
    • AnnotationUsage::type ? AnnotationUsage::type_id
    • TypeProperty::id ? TypeProperty::type_id
    • MemberProperty::id ? MemberProperty::member_id
    • MemberProperty::type ? MemberProperty::type_id

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Name the members in question more explicitly: member_id and type_id.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of built-in IDL annotation @Shared is missing

  • Key: DDSXTY-10
  • Legacy Issue Number: 15690
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The Type System defines a type member attribute shared, which indicates that a member should be stored by reference instead of by value to enable the use of external stores—for example, for large data members. This attribute appears in the TypeObject IDL definitions as a built-in annotation @Shared. However, this built-in annotation is never formally defined. (Possibly, it was deleted accidentally in a previous revision of the specification document.)
    Resolution:
    Add a section defining this built-in annotation to section 7.3.1.3, Built-in Annotations.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Add a section defining this built-in annotation to section 7.3.1.3, Built-in Annotations.
    Issue 15707, Improve support for shared data, needs to update the description of this new section. The FTF should not create the section in this issue only to modify it in that one. Rather, we should merge this issue with that one and make the entire change in one place.
    Revised Text:
    See issue 15707.
    Disposition: Merged with issue 15707

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of type “Parameters” inadvertently missing

  • Key: DDSXTY-12
  • Legacy Issue Number: 15692
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    The IDL definition of the type AnnotationDescriptor from the section Representing Types with TypeObject depends on a typedef “Parameters,” which is an alias to a string-to-string map. This type definition was present in earlier revisions of the IDL file but was inadvertently deleted in the adopted revision.
    Resolution:
    Restore the missing type definition.
    Revised Text:
    Add the following definition immediately before AnnotationDescriptor in the IDL file:
    typedef map<ObjectName, ObjectName> Parameters;

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    Restore the missing type definition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT