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.

Split the documents per instructions in the revised text section below

In the PSM for get_discovered_topic_data() and get_discovered_participant_data() on the DomainParticipant, the data parameter should be first followed by the handle. The order is correct in the PIM.

Proposed Resolution:
Make the suggested modifications.

Proposed Revised Text:

Section 2.2.3 DCPS PSM : IDL
In the DomainParticipant interface:

Change the order of the parameters to get_discovered_participant_data from "in InstanceHandle_t participant_handle, inout ParticipantBuiltinTopicData participant_data" to inout ParticipantBuiltinTopicData participant_data, in InstanceHandle_t participant_handle".

Change the order of the parameters to get_discovered_topic_data from "in InstanceHandle_t topic_handle, inout TopicBuiltinTopicData topic_data" to inout TopicBuiltinTopicData topic_data, in InstanceHandle_t topic_handle".

No Data Available

Filters and Queries are not compile-time checked and are too
heavy

The 04-04-12 DDS document proposes a subset of SQL for defining filters
andqueries.

The filter/query expressions are passed into the corresponding methods
as type "string".

First, this means that conforming implementations need to provide an SQL
expression parser/evaluator - a fairly complex piece of software.
Second, since the expressions are given as strings, checking them at
compile time is not straight-forward.

We request the Revision Task Force to reconsider this design decision
in favor of less heavyweight approaches that allow for compile-time
checks.

No Data Available