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

Extensible and Dynamic Topic Types for DDS — Closed Issues

  • Acronym: DDS-XTypes
  • Issues Count: 5
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

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