Data Distribution Service Avatar
  1. OMG Specification

Data Distribution Service — Closed Issues

  • Acronym: DDS
  • Issues Count: 3
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

DDS DLRL Issue: Clarify behavior of a Composition

  • Key: DDSDLRL-2
  • Legacy Issue Number: 10998
  • Status: closed  
  • Source: OCI ( Don Busch)
  • Summary:

    Add a new subsection:

    8.1.3.2.3 Compositions

    o A composition implies cascading deletion. When the owning object is deleted, the composed (i.e. owned) object is also deleted. When the owning object is deleted, its composed objects must also be present in the same CacheAccess so they too can be deleted. Failure to do this will result in a PreconditionNotMet exception on the ObjectRoot::destroy() call.

    o A composed (i.e. owned) object may only have one owner. Any attempt to set an owned ObjectRoot on two different owning object will result in a PreconditionNotMet exception

    Modify 8.1.6.3.14 ObjectRoot, by adding to the descriptions of the relevant operations:

    destroy: If the object has composition relations, all composed objects must be present in the CacheAccess. Otherwise, a PreconditionNotMet is thrown.

    set_attribute: If the attribute is a composition relation, the composed object must not be owned by any other object. Otherwise, a PreconditionNotMet is thrown.

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:
  • Updated: Mon, 12 Feb 2018 19:07 GMT

DDS DLRL Issue: Clarification on the use of a Set in a DLRL Query

  • Key: DDSDLRL-1
  • Legacy Issue Number: 10995
  • Status: closed  
  • Source: OCI ( Don Busch)
  • Summary:

    In a DLRL Query, there are [] operators to access members of a collection. For a Set, is the [] operator used to determine whether the value is in the set or not? Or does a "contains" operator need to be added to the query language?

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:
  • Updated: Mon, 12 Feb 2018 19:05 GMT

The DDS specification should be separated into two documents

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

    The DDS specification should be separated into two documents one for the DDS-DCPS layer and the other for DDS-DLRL layer.

    Details:
    Splitting the DDS specification into two separate specifications will simplify specification management and align better with the available implementations.

    The DDS-DCPS layer does not have any dependencies on the DDS-DLRL layer. Â DDS-DLRL is an optional compliance point built on top of DDS-DCPS.

    More than 9 vendors support DDS-DCPS whereas there are only experimental products with limited support that implement DDS-DLRL.

    The current situation where there is a single specification creates confusion and complexity. It forces each revision of the specification to handle the issues submitted against both DDS-DLRL and  DDS-DLRL. This is very cumbersome given that different companies support the different specifications and the fact that these companies have different priorities and timelines.

    The current situation is hard to sustain and has delayed the RTF work to the extent that RTF 3 closed without a report.

    Splitting the specification into two separate ones, one for the DDS-DCPS layer and the other for DDS-DLRL layer would solve these specification maintenance issues.

  • Reported: DDS 1.2 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Resolved — DDS 1.4
  • Disposition Summary:

    Split the documents per instructions in the revised text section below

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