In the ResourceLimitsQosPoliicy you can set limits to the amount of instances that you would accept on your Writers or Readers. However, it is unclear what should happen when an instance limit is violated on the Reader side.
Consider the following Use-Case:

• A Reader sets a ResourceLimit with max_instances is n.
• A matching Writer successfully transmits n ALIVE instances.
• Now the Writer transmits a new keyvalue for instance n+1, which violates the Reader limit.

What should the Reader do in this case? It should probably reject the sample, which for Reliable topics typically results in the Writer retransmitting it again at a later moment in time. In the mean time the Reader can consume some samples by taking them out of its cache, so that in a subsequent retransmission attempt the sample can now be accepted. However, in case of an instance limit violation, there is nothing the Reader can do to make room for new instances:

• Reader instances can only be purged if they are empty (i.e. all samples taken out) and the Writer has unregistered them.
• However, the Reader doesn't control the instance lifecycle, and so unless a Writer unregisters an instance, there is nothing the Reader can do to make room for the rejected instance.
• This could result in the Writer continuously retransmitting samples for the rejected instance, and the Reader continuously rejecting them.
• Even worse, even when the Writer wants to unregister an older instance at a later moment in time, it cannot deliver this unregister message until the rejected sample has successfully been inserted into the Reader history due to the order preservation requirements of the Reliable protocol.

All in all, if there is a mismatch between the max_instances setting between a Reader and a Writer where the Reader is more constrained than the Writer, there is a severe risk that the Writer cannot make any progress with respect to this Reader.

We might want to consider what to do in scenarios like this.

Class "TopicDescription" include 2 attributes, name and type_name,so the "no attributes" is error.
I'm study the spec , and i learned a lot, thank you, good wish to you!

The DDS specification states a Topic name is a string but it does not state what the legal characters are. It would therefore be possible to use "unprintable" characters which could create difficulties with printing and logginf messages.
Because of this it is also possible for multiple vendors to put in place restrictions that could cause incompatibilities.

For this reason it is desirable that the specification states with characters are legal within a Topic name.

In addition RTPS version 2.2 defines TopicName as string<256> this should also be reflected in DDS.

RTPS 2.4 added a domainTag (see Table 8.73 - RTPS SPDPdiscoveredParticipantData attributes) this was done to support having the DDS RTF adding it to the next version of the Spec. This task should be completed.

The domainTag is used to isolate domains even if they are on the same DDS domainId

We have some customers that have different history requirements for live data and for historical (i.e. TRANSIENT_LOCAL) data:

• For live data flows, they don't want to miss any sample (i.e. KEEP_ALL).
• For historical data for late joiners they don't want to align the entire history, but only the most recent subset (e.g. KEEP_LAST with depth=1).

In the current spec, it is not clear how to facilitate both requirements in the same Writer. Some vendors have added proprietary features (new QosPolicy attributes or new Writer properties), but it would be nice if the DDS spec would offer a formal way of facilitating this, one that is portable between different vendors.

The DDS specification is very clear what happens in case of a disconnect: the receiver will behave as if the sender unregistered all its instances. But what should the behavior be in case of a reconnect?

For VOLATILE cases the behavior might still be intuitive: an instance stays NOT_ALIVE_NO_WRITERS until an update has been received, in which case it goes back to ALIVE. And because VOLATILE data is typically periodic data, eventually all my instances will come back alive.

But what about non-volatile data, that is typically not periodic, or is periodic but with a very low update frequency? Consider the following scenario:

• Writer A writers 10 samples belonging to 10 different instances.
• Reader B takes all samples.
• Writer A disconnects from Reader B.
• Reader B receives invalid samples indicating all instances are now NOT_ALIVE_NO_WRITERS.
• Reader B takes these samples.
• A reconnection is established, and none of the instances have been updated by Writer A.

You would expect that all instances in Reader B would go back to the ALIVE state, but how do I get them back into the ALIVE state? Since there are no more samples to piggy-bag this instance state change on.

A couple of approaches are conceivable:

• Use an invalid sample to bring the instance back alive.
• Republish the last available sample
• Do nothing.

Every approach has its pro's and cons, but the DDS spec should clearly describe which behavior is intended here.

The specification should specify how string parameters should be escaped when used within a query string, for example a query_expression of "name = 'bar'", but what if bar is a string with a single quote, newline, tab, etc? The specification should specify the escaping rules for that.

The DDS spec is not clear about what should happen in the following scenario:
A reader is RELIABLE and KEEP_ALL, with max_instances set to n. A matching Writer is found, but this Writer doesn't have a similar instance limit. (Or alternatively, there are multiple Writers that together violate the instance limit of the Reader.)

Now in this case, the Reader accepts the first n instances, but when instance n+1 is received it rejects the incoming sample based on exceeding its configured max_instances. But what should happen next? If I permanently drop that sample I violate the Reliability and/or KEEP_ALL policy. If I try to retransmit it, I would very likely run into the same instance limit over and over again, since instances will only be purged when unregistered by the Writer and consumed on the Reader side.

So in the given scenario, should we expect the Writer to keep re-transmitting instance n+1 (subsequently blocking out any other samples following the rejected sample potentially belonging to existing instances due to the order preservation requirements of the Reliability policy?),. or should we expect it to just give up when a sample was rejected by instance limit? In the latter case, would this mean that the Reader would just acknowledge a Rejected sample just to avoid the Writer from retransmitting it? And should the Reader just expect a rejected instance to be lost forever?

And what happens if another instance gets purged, making room for the instance we just rejected before? For VOLATILE, BEST_EFFORT data it might be acceptable that you wait until the next update for this instance arrives, but what if the data is TRANSIENT_LOCAL or above? How does the Reader even ask for retransmission of the rejected sample, given that it might have already acknowledged it before?

I short, I think the spec should make more clear what the consequences are of an instance limit violation on the Reader side.

The description of the history depth QoS setting indicates it is optional and only used when KEEP_LAST is the history kind, and that it is a long (or sometimes referred to as an integer/int), and that the default value is 1, and that it needs to be consistent with related RESOURCE_LIMITS QoS settings, but it does not specify a bounds nor does it explicitly state that the bounds are actually any valid (signed) long value. So a few boundary cases are not well defined, for example:

• is KEEP_LAST with depth 0 valid? If so, is it a special behavior?
• what about negative values for depth?

RTI's Connext Pro documentation limits it to values greater than zero and less than 100,000,000:

> "[range] [1,100 million], <= DDS_ResourceLimitsQosPolicy::max_samples_per_instance"
– https://community.rti.com/static/documentation/connext-dds/6.0.1/doc/api/connext_dds/api_c/structDDS__HistoryQosPolicy.html#aef0fb3fd3579866be17d1a936f5e3729

Other implementations like Cyclone DDS and Fast-DDS will accept values of zero, though it's not clear what they're behavior is in that case.

Those are useful to imply what the behavior is, but I think the standard should probably take stance on the valid values for depth, and I think values >= 1 makes sense, though the "100 million" upper bound set by RTI's API seems kind of arbitrary, though I don't have a better alternative in mind.

The bullet point for " This profile adds two things " goes on to list three things. The third is about History QoS, which makes it appear to the reader like this was added on later and not initially part of the profile. That itself is not a problem, but for clarity this section should provide a rationale as to why the History QoS Policy is involved in the definition of Ownership Profile.

Suppose the DATA_AVAILABLE StatusChangedFlag (see Figure 2.16) is set on a DataReader and then a listener (with DATA_AVAILABLE_STATUS in its mask) is attached to the DataReader by the user calling set_listener(). The specification does not specify if the listener should be invoked. If the decision is that the listener is not invoked, then guidance should be given to users that they may need to invoke the listener manually.

The PIM contains definitions for most of the "reference semantic" classes. But it does not directly define the "value semantic" classes such as: Time_t, Duration_t, SequenceNumber_t, InstanceHandle_t, StatusKind, StatusMask, etc.

Some types like ReturnCode_t are defined. But this is done in an odd place: (section 2.2.1.1 'Format and Conventions').

The PIM would be more clear if these types were all defined clearly in a centralized place. For example the Infrastructure module.

This issue should be treated as a "Blocker" so it is resolved ahead of other issues. That way the other issues can refer to the new definitions and organization.

The specification does not fully define the meaning of a Duration_t when the second part is negative.

struct Duration_t {
    long sec;
    unsigned long nanosec;
};

What is he interpretation of a value when sec <0?
Does the nanosec part get interpreted to have the same sign?
If so, then the number between 0 < x < -1 cannot be represented

So the most logical way to interpret a negative value for the sec field appears to be:

value = sec + nanosec 

where sec can be positive or negative but nanosec is always positive.
So the value of negative 1ms would be represented as:

sec = -1
nanosec = 999,000,000

The specification should define the proper interpretation.

2.2.3 (p. 96) The DataReader requests that liveliness of
the writers is maintained by the requested
means and loss of liveliness is detected with
delay not to exceed the lease_duration.
The DataWriter commits to signalling its
liveliness using the stated means at
intervals not to exceed the lease_duration.

Since both the DataReader and DataWriter have a lease duration, the reference to lease_duration is ambiguous.

2.2.3.11 (p. 107) Changes in LIVELINESS must be detected by the Service with a time-granularity greater or equal to the lease_duration. This
ensures that the value of the LivelinessChangedStatus is updated at least once during each lease_duration and the related
Listeners and WaitSets are notified within a lease_duration from the time the LIVELINESS changed.

Same problem, the reference to lease_duration could refer to the writer or the reader.

Other sections not mentioning the lease_duration may have similar problems.

The language around on_liveliness_changed implies that changes (listener, wait set) must be communicated at least once for every lease_duration of the DataReader.

The spec should clarify three things:
1. How often does the DataReader evaluate the liveliness of a DataWriter? Is this at a period of at most the DataReader's lease_duration or a period of at most the DataWriter's lease_duration?
2. When the DataReader evaluates the liveliness of a DataWriter, which lease_duration should it use, the lease_duration of the DataReader or the lease_duration of the DataWriter?
3. Are the rules for evaluating liveliness for the purpose of ownership the same as for listeners and waitsets? This question is particularly vexing because it can lead to inconsistency where ownership should be eventually consistent.

To illustrate the problem, consider the following a system using exclusive ownership.

• Writer 1 has a lease_duration of 1 second but only writes/asserts every 4 seconds. Ownership strength of 1.
• Writer 2 has a lease_duration of 1 second but only writes/asserts every 4 seconds. Ownership strength of 2.
• Reader 1 has a lease_duration of 2 seconds.
• Reader 2 has a lease_duration of 4 seconds.

Let events happen according to this sequence:

If we assume that the readers evaluate liveliness at a period of their own lease_duration using their own lease_duration, then Reader 2 will always see Writer 2 as the owner while Reader 1 will toggle ownership between the writers. Thus, there is no eventual consistency of exclusive ownership.

If we assume that the readers evaluate liveliness at a period of their own lease_duration using the lease_duration of the writer, then both readers will consistently toggle and never see a live writer.

If we assume that the readers evaluate liveliness independently for each writer at the lease_duration of the writer, then the readers will see ownership toggling but periods where writers are alive.

Ideally, liveliness would be objective and not subjective. That is, liveliness should be based on the behavior of the writer interpretted by its lease_duration. Different readers may observe different things leading to temporary inconsistency, but eventual consistency would be guaranteed.

If the spec choose a subjective approach, then language should be added that warns the reader of the problem and the consequences like ownership not working as expected.

DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038, almost all operating systems are now defining time as 64bit, shouldn't DDS do the same?

In addition, the the standard does not define the calendar time of Time_t at

This is required in order to convert a Time_t to/from a system's native time (such the the type time_t on Unix systems which has the calendar start time 1970-01-01 00:00:00).

This issue should be treated as blocker so that it is resolved ahead of other issues.

• Align naming of annotations with the latest versions of said specifications.
• Use the new size-aware typenames: int32_t, uint32_t etc. Instead of the classic ones.
• Use bitmask where it makes sense. For example the StatusKind, InstanceStateKind, ViewStateKind and the corresponding
• StatusMask, InstanceStateMask, ViewStateMask? Will this negatively impact /break the Java, C#, C++ APIs?
• Use enum for ReturnCode_t, QosPolicyId_t? Will this negatively impact /break the Java, C#, C++ APIs?
• Use template modules to model the Implied IDL related to type 'Foo'?
• Apply the @extensibility annotation to the BuiltinTopicData types and the types they reference (e.g. QosPolicy types) since they are serialized to be sent to other peers. Note that this was already done in XTYPES so we can copy those definitions to the DDS spec and remove them from a future revision of XTYPES.

In 2.2.2.1.1.8 the Instance handle is mentioned by the spec lacks some definition of InstanceHandle_t. In how far as instance handles unique and should they be comparable? Are they unique system wide or process wide? Is it legal to have two DDS entities (for example two domain participants) to have the same instance handle? This is important for users who for example store DDS entities in a std::map.

Section 7.6.4.2 Operation: DomainParticipant::lookup_topicdescription
in XTYPES 1.3 makes a changes to the DDS spec in the description of the Operation: DomainParticipant::lookup_topicdescription

This change should be consolidated into the DDS specification.

It is ambiguous whether or not the PartitionQosPolicy set for a Publisher or Subscriber should affect DataWriter and DataReader matching, and how an implementation should handle it.

Since it is stated that failure to match partitions does not imply "incompatible" QoS, it would seem it does not affect matching.
If so, the specification should be clearer with regards to

• whether this is filtered on the publishing, or subscribing side (or both)
• how partitions are tied to samples or instances e.g. when written from a DataWriter whose Publisher changes partitions intermittently
• how it deals with late joiners and historical data
• how this affects the "transient/persistent" services and their entities' QoS settings

2.2.3 QosPolicy Table

A DataWriter within a Publisher only communicates with a DataReader in a Subscriber if (in addition to matching the Topic and having compatible QoS) the Publisher and Subscriber have a common partition name string.

2.2.3.13 Partitions

For a DataReader to see the changes made to an instance by a DataWriter, not only the Topic must match, but also they must
share a common partition. Each string in the list that defines this QoS policy defines a partition name. A partition name may
contain wildcards. Sharing a common partition means that one of the partition names matches.
Failure to match partitions is not considered an “incompatible” QoS and does not trigger any listeners nor conditions.

It is not clear what kind of restrictions there are to find_topic/delete_topic.

Assume two software modules in the same process, order of instantiation is not fixed, also more modules could be loaded by a configuration file. All modules use find_topic to find topic Foo, the first module now calls create_topic to create the topic, second module gets topic Foo through find_topic.

Each module now creates its own datareader/datawriters using the topic it retrieved. At the moment the module now ends it cleans the datareader/datawriter it has created and now calls delete_topic. It is not clear what at that moment delete_topic will return for the module that has successfully used find_topic to get the topic. Some DDS vendors return RETCODE_OK, some RETCODE_PRECONDITION_NOT_MET because there are still readers/writers related to that topic (but the other module did use create_topic). The shutdown order can also be swapped, so first the module that used create_topic will be removed, the one with find_topic keeps running.

The description of find_topic should be extended to clarify how it behaves related to delete_topic? Personally I think RETCODE_OK should be returned when there is no DataReader, DataWriter, ContentFilteredTopic, or MultiTopic attached anymore to the topic returned by find_topic, independent of the entities attached to the topic as it was created by create_topic (or a different find_topic call)

It is not clear what should be done if the user calls read, take, or any of their variants when the following conditions are met:

1. The method is called with max_samples = 0
2. There is data available that would be returned with max_samples > 0

I think we have two options here:

1. Return NO_DATA
2. Return OK with a resulting collection with len = 0

The last sentence of the section seems to indicate the latter...

If the DataReader has no samples that meet the constraints, the return value will be NO_DATA

... but the definition of NO_DATA on page 5 seems to indicate the former (as no data is returned)

Indicates a transient situation where the operation did not
return any data but there is no inherent error.

when testing for sample lost/rejected between multiple DDS vendors we see different vendors to different things. The specification should be extended with more information when a sample is considered lost and when rejected with also more details how QoS settings would influence this. We see that vendors have extended the SampleLostStatus and SampleRejectedStatus and even have deprecated some of its members, this should be handled in the specification so that the user gets the same behavior when using multiple vendors

There looks to be different interpretations between DDS vendors how implied IDL and language mappings interface. The specification lists in 2.3.3 the example of type Foo which results in the implied IDL DataWriter named FooDataWriter. On this implied IDL the concrete language mapping is applied, so with IDL to C++ we get FooDataWriter/FooDataWriter_ptr/FooDataWriter_var. But, what happens when the type is a IDL or C++ keyword, for example the type _public results in the implied IDL publicDataWriter, on which the IDL to C++ language mapping is implied, so to our idea you get _cxx_public/publicDataWriter/publicDataReader. The IDL to C++ language mapping only sees the identifiers as resulted by the implied IDL rules. Some vendors do generate _cxx_public/_cxx_publicDataWriter/_cxx_publicDataReader which means the implied IDL and IDL to C++ language mapping are strangely mixed. A generaic modeling tool for example only knows of implied IDL, a custom code generator generates the code for the specific language mapping.

The specification should give an example for _public, what does the programmer now get in a specific programming language, for example C++

The IDL file dds_dcps.idl has a wrong value

const string GROUPDATA_QOS_POLICY_NAME = "TransportPriority";

Shouldn't it say "GroupData"

Above the Myclass example table, the written text says that collections of types will be denoted by <type>[]. The example describes in: param4 as being a collection of longs, but the table defines the type as long rather than long[] as the written convention seems to imply.

DDS Entities (DomainParticipant, Publisher, Subscriber, DataReader and DataWriter) have associated GUID but the current API does not provide any way of associating them a symbolic name, such as "com.acme.mycoolapp.DomainParticipantFoo"

The DDS PIM should be extended to support the explicit setting of entity names. When not set explicitly, vendors should be free to pick meaningful names.

We identified differences between DDS vendors how to handle a query condition that uses a string parameter. At the moment we have a query with "symbol = %0", what is the query parameter string we need to use when we want to match it with OMG. When using for example C++, RTI Connext DDS seems to require "'OMG'", so single quotes around the string itself, but OpenDDS/Opensplice seem to use "OMG" so without single quotes around the string.

The specification should be clear about how strings are used when they are passed through a query parameter like %0.

Several DDS vendors have already extended SampleLostStatus with a last_reason, indicating why the last sample was lost. We would like to see this in the DDS specification so that all vendors provide this consistently

the DDS spec should define the behaviour when the create_topic is called multiple times with the same topic_name, I think the operation should fail at that moment, but that is not mentioned in the spec

Problem:
QoS settings of buildin Readers: according to section 2.1.5 builtin Readers should have its ReaderDataLifecycles delays set to infinite, meaning that builtin topics that are disposed and/or unregistered will never be removed from the system unless explicitly 'taken'. If an application never bothers to look at the builtin readers, they will never clean up resources and these readers will use up more and more memory if entities keep on joining and leaving the network.

Solution:
We propose to give the builtin-readers a finite duration for both auto_purge variables (for example something like 5 minutes).

Unregistering and disposing instances have different semantics and the default association of these two operations through the usage of the autodispose_unregistered_instances may lead to behaviors that are unexpected and not desirable to DDS users.

The unregister operation is meant to indicate that the DataWriter will no longer update the instance but does not indicate anything about the state of the instance itself. The dispose operation, on the other hand, is meant to indicate a change in the state of the instance, it indicates that the instance has been deleted. Because of this, we are proposing changing the default value of this QoS to FALSE. This is something that many of our customers end up doing explicitly.

In addition to changing the default value for autodispose_unregistered_instances, we are also proposing that this QoS does not have any effect during the deletion of the DataWriter. Disposing of an instance should be an explicit operation (individual or bulk operation). In many cases, the user's intention is not to delete (dispose) an instance when a DataWriter is deleted and doing so explicitly ties the lifecycle of the instance to the lifecycle of the DataWriter.

p2 5th para middle sentence

The purpose of the DDS specification is to
define the standardized interfaces and behaviors that enable applicaton portability.

-> application

p11 Figure 2.5 bottom right class box,
p58 Figure 2.10 bottom middle class box,
p125 Figure 2.19 middle right class box

QueryConditon

-> QueryCondition

p61 2.2.2.5.1.4 1st para 3rd sentence

change of state for an intance that was caused by some internal mechanism

-> instance

p61 2.2.2.5.1.4 1st para 4th sentence

An example of this situation is when the Service [...] and changes the coresponding

-> corresponding

p61 2.2.2.5.1.4 2nd para 2nd sentence

The application can distinguish wether a particular DataSample has data

-> whether

(DDS15-195)
p61 2.2.2.5.1.4 3rd para 1st sentence

To ensure corerctness and portability, the valid_data flag must be examined

-> correctness

p107 2.2.3.13 4th para 3rd sentence

It may establish new "matchs" that did not exist before, or break existing matchs.

-> "matches" , matches.

p110 2nd para 2nd sentence

[...] For example setting
max_samples_per_instance to LENGH_UNLIMITED will cause the middleware to [...]

-> LENGTH_UNLIMITED

p120 2.2.4.2.2 enumerated list 2nd bullet 2nd sub-bullet

• the DataWriter that owns it if OWNERSHIP QoS kind=EXLUSIVE, or by

-> kind=EXCLUSIVE

p121 Figure 2.16 statebox at right

StatiusChangedFlag = TRUE

-> StatusChangedFlag

p166 top

Selection        ::=    TOPICNAME
                 |      TOPICTNAME NaturalJoin JoinItem

-> TOPICNAME NaturalJoin JoinItem

Suspected typo in paragraph 4, last scentece:
"In other words, the DataReader may miss some data-samples but it will never see the
value of a data-object change from a newer value to an order value."

Should the second to last word "order", not be: "older"? The context seems to suggest so.

According to the Qos table in 2.2.3 'Supported QoS' the default value for autodispose_unregistered_instance is TRUE. We have found a two issues with this

(1) It is not semantically what people expect. Just because a DataWriter is deleted it does not mean all the instances should be deleted... It could be so for some use-cases, but we found that in the majority of the use-cases it is not an intuitive behavior.

(2) It is not scalable. If writer with a lot of instances is deleted. it needs to send many messages and potentially wait until they are acknowledged before releasing the DataWriter resources. This makes the data-writer delete operation something that can block for an unbounded time which is not what applications expect.

It sees it would be better to:
(a) Change the default value of autodispose_unregistered_instance to FALSE.
(b) Provide a better/more efficient/scalable way to communicate to the DataReaders that all the instances of a DataWriter have been deleted.

The Domain Participant Factory may create resources (e.g. tables that allow looking up or manage created domain participants, etc.)

These resources need to be released when the application shuts down so that they are not reported as "leaks" by the OS.

A function should be added that forcefully releases all resources created by the DomainParticipantFactory. This function would have as a pre-requisite that all DomainParticipants have been deleted...

This issue has to do with the proper code when the function
get_discovered_participant_data gets passed an invalid handle.

This function is analogous to get_matched_subscription_data() and get_matched_publication_data() except that that it retrieves information on the matching participant instead of the matching endpoint. All these functions take a handle as an input that refers to the "matching" entity for which information is
being retrieved.

Prior to version 1.2 get_matched_subscription_data() was returning PRECONDITION_NOT_MET and get_matched_publication_data BAD_PARAMETER.
Returning BAD_PARAMETER seemed more appropriate so in version 1.2 (OMG issue 9500) we updated get_matched_subscription_data to also return BAD_PARAMETER.

However get_discovered_participant_data() was not updated as part of is still returning PRECONDITION_NOT_MET.

Therefore get_discovered_participant_data() should be updated to also return BAD_PARAMETER when an invalid handle is passed.

Define InstanceHandle_t as a structure that contains native data
Define DomainId_t as an integer

InstanceHandle_t is underspecified, The IDL PSM that should use a struct, so that argument passing is the same for all values

In the IDL PSM, I see that copying and comparing instance handles is underspecified.

The same issue applies to domain IDs, actually, which also have unspecified contents in that PSM.)

Section 2.3.2 on page 138 contains:

The two types used to represent time: Duration_t and Time_t are mapped into structures that contain fields for the second and the nanosecond parts.

However, the standard does not define the calendar time of Time_t at

.
This is required in order to convert a Time_t to/from a system's native time (such the the type time_t on Unix systems which has the calendar start time 1970-01-01 00:00:00).

In Figures 2.9, 2.10, and 2.17, the Data*Listener classes in the UML incorrectly have functions called

on_*_match()

when in fact they should be

on_*_matched()

In MyClass table on page4 (pdf page 16/180), param4 is given type long. But the description says above:"‘param4,’ is also an input parameter of type collection of longs"
So it must be "long []" instead of "long".

I checked the DDS 1.2 spec (formal/07-01-01), it was correct in that version (pdf page 18/260).

Akif,

The DDS-RPC added a @Choice annotation (see 7.5.1.2.1.1 @Choice Annotation) to indicate a Structure with the "single-member" semantics of a union. As stated in the aforementioned section the reason was:

Using unions to indicate which operation is being invoked is brittle. Operations in an interface have set semantics and have no ordering constraints. Union, however, enforces strict association with discriminator values, which are too strict for set semantics. Further, use of unions leads to ambiguities in case of multiple inheritance of interfaces.

However XTYPES 1.2 enhanced unions which now support inheritance and are not so brittle anymore. For this reason it makes sense to re-evaluate this decision.

An advantage of using unions (beyond avoiding a extraneous annotation) is that their API is better oriented to identifying the one branch that is present; whereas in the case of structures there is no standard API available to determine which member is present other than iterating over every member. This would be unnatural for processing the RPC calls.

Section 7.6.3.1.3 'DataRepresentationQosPolicy: Platform-Specific API' states:

The topic, publication, and subscription built-in topic data types shall each indicate the data representation of the associated entity with a new member:

@id(0x0073) DDS::DataRepresentationQosPolicy representation;

This does not follow the naming conventions for field names. Instead it should have said that the new member should be:
@id(0x0073) DDS::DataRepresentationQosPolicy data_representation;

Likewise in Annex D the declarations of structures TopicBuiltinTopicData, TopicQos, PublicationBuiltinTopicData, DataWriterQos, SubscriptionBuiltinTopicData, and DataReaderQos all have the member:

@id(0x0073) DDS::DataRepresentationQosPolicy representation;

This should be changed so the member is:

@id(0x0073) DDS::DataRepresentationQosPolicy data_representation;

While this is a very minor issue, it is a good idea to mention it. In the line starting with "To ensure corerctness and portability" I guess it is meant "To ensure correctness and portability", thus having a typo in "corerctness". Am I right?

Kind regards,

Jesús Rodríguez-Molina

In the DDS specification version 05-03-09, page 2-1 specifies that the PSM is for the OMG IDL platform. In section 2.2.1 (page 2-193), more detail is given as to what this PSM looks like. One area I don't see covered is the subset of OMG IDL that the DDS specification supports from a user's perspective. When a user defines an IDL file, what data types should and shouldn't be used? It looks as though valuetypes are not supported, but is it possible to explicitly specify what OMG IDL types are supported by implementations of the DDS specification?

Problem:
In the QoS table (Section 2.2.3 Supported QoS) the 'concern' row illegally specifies the DataWriter for the DURABILITY_SERVICE QoS.

Solution:
Section 2.1.3 Supported QoS, QoS Table:
Entry for DURABILITY_SERVICE QoS, remove the word 'DataWriter' from the 'Concerns' column.
If we do this it would need to be removed from the BuiltinPublicationData.

In 7.2.3 the defines DATAWRITER_QOS_USE_TOPIC_QOS
and DATAREADER_QOS_USE_TOPIC_QOS do exist but they are not mentioned anywhere in the spec. Not sure if they should be removed, or documented

The DDS v1.2 specification does not explicitly define the subset of IDL that can be used to express Topic Types. From the specification, it can be inferred – and all vendor have done so – that a topic type is defined by means of a struct and that the IDL types that cannot be used for the attributes of this struct are Value-Types, Any Types and Object References.

The DDS v1.2 should explicitly state this. Notice the the problem is not solved by the X-Types specification as that introduces a set of types, such as Maps, Optional types, etc. that are not supported by DDS v1.2 implementations.

This is really a critical matter which is trivial to solve. Just state what is implicitly assumed and should be fixed ASAP.

Summary:
In the QoS table (section 2.1.3. Supported QoS) the 'concerns' row illegally specifies the DataWriter for the DURABILITY_SERVICE QoS.

Proposed Resolution:

Proposed Revised Text:
Section 2.1.3 Supported QoS, QoS Table:
Entry for DURABILITY_SERVICE QoS, remove the word 'DataWriter' from the 'concerns' column.

Context: "For each instance the middleware internally maintains an instance_state." Obviously this instance_state could be different for different DomainParticipants. Might it be different for two Subscribers of the same DomainParticipant? How about two DataReaders of the same Subscriber?

Context: "The application may pass nil as the value for the type_name. In this case the default typename as defined by the TypeSupport (i.e., the value returned by the get_type_name operation) will be used." What happens if register_type is given a type_name that differs from the result of get_type_name?

The class description for TopicDescription says "no attributes" but in fact two attributes are listed immediately below.

Context: "The resulting type is specified by the type_name argument." What happens if the specified type is inconsistent with the subscription_expression?

I was looking at the DDS specification and saw that the name of the first parameter for DomainParticipant's create_contentfilteredtopic method is "name" in the table of methods (section 2.2.2.2.1) and it is "topic_name" in the method description (section 2.2.2.2.1.7). I assume the name should be consistent.

Context: "The use of this variant allows for zero-copy access to the data and the application will need to “return the loan” to the DataWriter using the return_loan operation (see Section 2.1.2.5.3.20 )." Should be DataReader?

Context: "In other words, the DataReader may miss some datasamples but it will never see the value of a data-object change from a newer value to an order value." You mean "older".

Context: "The “persistence service” is the one responsible for implementing the DURABILITY kinds TRANSIENT and PERSISTENCE." You mean PERSISTENT

Context: "And three integers: history_depth, max_samples, max_instances, max_samples_ per_instance" There are four integers here.

While reading the DDS specification, 'Data Distribution Service for Real-time Systems Version 1.2 OMG Available Specification formal/07-01-01', I found that the 'synchronous' and 'asynchronous' was switched as highlighted in red in the below paragraph in the spec.

<section 2.2.1.2.2 'Overall Conceptual Model', page 9, penultimate paragraph>
On the subscriber's side however, there are more choices: relevant information may arrive when the application is busy doing something else or when the application is just waiting for that information. Therefore, depending on the way the application is designed, asynchronous notifications or synchronous access may be more appropriate. Both interaction modes are allowed, a Listener is used to provide a callback for synchronous access and a WaitSet associated with one or several Condition objects provides asynchronous data access.

The DDS Spec (as of v1.2) does not specify the set of IDL types that are allowed in a DDS Topic struct. This should be defined and made normative instead of being left as an implementation detail.

Discussion:

Because the set of IDL types allowed in a DDS Topic struct is not defined, implementors are at liberty to decide what set of IDL types to support. Concerns about the impact of the lack of standardization in this area have been raised by the computing infrastructure teams on major Navy programs on several occasions particularly in regards to potential impact on code portability across DDS implementations and interoperability between DDS implementations.

In reviewing the DDS C++ Native Language Mapping RFP, we commented that the RFP provided an opportunity to insert a requirement to define the allowed C++ types within a DDS Topic struct which would indirectly result in defining the set of allowed DDS IDL types due to the RFP requirement for the C++ mapping to be consistent with the IDL mapping. This suggestion was rejected because it was viewed that the correct forum and mechanism for resolving this issue was the DDS RTF. We were requested to submit this as an issue to the RTF since the RTF could probably resolve this issue within the next 6 months.

1. Section 2.2.4.4 Conditions and Wait-sets - Two paragraphs above figure 2.19 is "The blocking behavior of the WaitSet is illustrated in Figure 2.19" I think this is meant to reference figure 2.20 instead.

2. Section 2.2.6.2.2 Notifications via Conditions and Wait-Sets - starts out with "The first part of Figure 2.22" I think it should be figure 2.23

3. In section 2.3.3 DCPS PSM : IDL on pages 152 - 153 are definitions of all the IDs and names of the QOS Policies with the exception that "TRANSPORTPRIORITY" has an ID definition but is missing a name definition.
4. Section 2.2.2.2.2.7 set_qos
This operation sets the value of the DomainParticipantFactory QoS policies. These policies control the behavior of the object a factory for entities.

The PSM mapping of BuiltinTopicKey_t is defined to be as:

struct BuiltinTopicKey_t { 
    BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3]; 
}; 

But the DDS Interoperability Wire Protocol (RTPS) specifies that GUID consists of 12 bytes GuidPrefix and 4 bytes EntityId.

In order to map GUID and BuiltinTopicKey, we should define BuiltinTopicKey as either

typedef octet BuiltinTopicKey[16];

or else if we really wanted to preserve the definition as an array of longs

struct BuiltinTopicKey_t { 
    BUILTIN_TOPIC_KEY_TYPE_NATIVE value[4]; 
}; 

But the latter could cause problems due to different endianess unless we also specified how to place the octets that arrive at the protocol level into the array of long.

The specification provides no way to way to specify a different history depth used for DURABILITY than the used for reliability...

The HISTORY depth is sometimes needed for reliability in order to accommodate bursts. But this means that the amount of data kept for DURABILITY is affected.

What is desirable is to have a setting that allows the DURABILITY depth to be decoupled from the RELIABILITY.

The mapping of user written IDL to C++ is not described in the version 1.2 of the DDS standard.

Is it expected that DDS use the existing CORBA C++ mapping for data types? If so then the standard should state this requirement.

On the other hand, the CORBA IDL to C++ mapping is fairly old. The new DDS PSM for C++ would suggest a more modern mapping.

For example, for bounded strings and bounded sequences, C++ classes inspired by the Standard Template Library (STL) could be used. These classes need not necessarily break the DCPS compatibility with the C language mentioned in 8.2.1.1. (Use fixed buffer, avoid virtual methods.) It is not clear whether unbounded data types need be supported, see issues 8892 and 12360.

In case a new mapping is defined which is independent of the CORBA C++ mapping, there is a problem to address:
Bridge applications which use both CORBA and DDS would need to translate a single IDL file twice, once for CORBA and again for DDS. Then there is an overlap in the generated names. This problem could be solved by encapsulating all C++ code generated for DDS from user IDL in an extra namespace.

The DDS specification document does not prescribes a specific package definition for the entities of the model in case of JAVA language binding; in the IDL only a "DDS" module is defined which does not result in a strictly specified package structure (it might only imply that the entities belong to the DDS package/namespace). It would be useful to have a precise statement indicating at least for the JAVA binding the packages to which the DDS Entities must belong in order to have all implementations using the same packages for the same Entities (e.g org.omg.dds.infrastructure, org.omg.dds.domain, etc..)

The CORBA specification (08-01-04) in section 7.11.6 deprecates the use of anonymous types, for example the type of the struct field "seq" below:
struct Foo

;

The DDS DCPS IDL uses these in multiple places (the first is DDS::UserDataQosPolicy). These should be replaced with non-deprecated usage such as:
typedef sequence<octet> OctetSeq;
struct Foo

;

This will also increase internal consistency of the DDS spec, since it already uses a DDS::StringSeq typedef in the PartitionQosPolicy struct.

Furthermore, if the element type of the sequence is a Basic Type or a String Type, the CORBA module already provides these typedefs, so it would be preferable to use them. The example above becomes:
struct Foo

;

GROUPDATA_QOS_POLICY_NAME is given as "TransportPriority", and the corresponding *_POLICY_NAME from TRANSPORTPRIOIRTY is missing.

Index: dds/DdsDcpsInfrastructure.idl
===================================================================
--- dds/DdsDcpsInfrastructure.idl
+++ dds/DdsDcpsInfrastructure.idl
@@ -327,7 +327,8 @@
     const string WRITERDATALIFECYCLE_QOS_POLICY_NAME = "WriterDataLifecycle";
     const string READERDATALIFECYCLE_QOS_POLICY_NAME = "ReaderDataLifecycle";
     const string TOPICDATA_QOS_POLICY_NAME           = "TopicData";
-    const string GROUPDATA_QOS_POLICY_NAME           = "TransportPriority";
+    const string GROUPDATA_QOS_POLICY_NAME           = "GroupData";
+    const string TRANSPORTPRIORITY_QOS_POLICY_NAME   = "TransportPriority";
     const string LIFESPAN_QOS_POLICY_NAME            = "Lifespan";
     const string DURABILITYSERVICE_POLICY_NAME       = "DurabilityService";

The current DDSv1.2 specification provides a slightly different semantics for the history on the writer side and on the reader.

In addition, the DDS v1.2 specification allows to use the data-writer history as the "reliability-send-queue" – this is combined with the fact that History is (correctly) not an RxO policy leads to a serious bug in the spec (luckily not all DDS implementations follow this path) . Let's try to understand why.

Firs, it is important to comprehend that unless a data writer uses KeepAll history, reliable data delivery is not guaranteed to matching data readers. This can't be guaranteed even when using Reliable communication (obviously ignoring data-writer crashes for the time being).

Essentially, under this scheme a DataWriter is allowed send/re-send only what is in its history cache. If a sample is out of history a DataWriter won't do anything, thus leading to potential inconsistencies in case some reader has lost the message.

Things get very messy when a DataReader with KeepAll History is matching a DataWriter that does uses KeepLast(n). In this case, the poor DataReader which might legitimally expect to have on his history all the samples written by the writers – without holes – might finds him-/her-self surprised by the fact that some samples might be missing.

The DDS spec defines: #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t; We see that some vendors use long, other a struct containing an octet array. This is causing problems when integrating DDS into CCM. A CORBA::Long is passed by value, a struct is passed as const &. At least the way the InstanceHandle_t is passed to methods and returned should be the same. We propose to change this type to: struct NativeInstanceHandle_t

; typedef NativeInstanceHandle_t InstanceHandle_t; That way we always have a struct passed as const&.

For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec, this way the IDL isn't complete and compilable Also MultiTopic::get_expression_parameters has the same issue Also DataWriter::get_liveliness_lost_status has this issue

UserDataQosPolicy, TopicDataQosPolicy, and GroupDataQosPolicy use an anonymous sequence, this is deprecated in IDL. A new typedef for this should be introduced

Page 2-70, The get_sample_lost method seems to be part of the Subscriber class. However, according to the UML-diagram page 2-62 and the idl-listing page 2-166 and , the get_sample_lost method should belong to the DataReader class - not the Subscriber.

In a CCM/DDS4CCM based system not all IDL defined types are intended to be used with dds. At this moment there is not a standardized way to indicate that a type should be usable with DDS. If I now have a large file with a lot of types, DDS just assumes that everything should be transmittable through DDS and generates a lot of code. Just like can indicate the keys of a struct, I think DDS should define a standardized way to annotate the idl so that just some types in a file are handled by the dds tooling

DDS leaves domainid, handle, and topic key to the dds vendor, each can define their own type for these. The specification has defines for them, but the default is long. If now a vendor uses for example a struct for the InstanceHandle_t, this leads to challenges when writing portable C++ code because the argument passing is different between a long (as value) or a fixed struct (const &). To my idea the dds specification should be more precise on the type, maybe fixed struct to achieve more portability of users code

We want to propose to extend the DDS status masks with DDS::STATUS_MASK_NONE which is defined as 0. This is cleaner for application code.

DDS has several methods to create entities and pass a listener. With the listener than a mask has to be passed. It would be much cleaner for some C++ systems when we can pass a special mask which means that DDS will callback on the listener to gets its mask, this reduces the application code and could lead to a cleaner user code architecture

Many vendors already extend the SampleInfo with some additional fields:

• The reception_timestamp
• The writerSequence number.

I would propose we make these part of the new standard.

The spec defines the following:
7.1.2.1.1.8 get_instance_handle
This operation returns the InstanceHandle_t that represents the Entity.

But it doesn't specify in how far this InstanceHandle_t has to be unique. When the user receives an InstanceHandle_t, is it than unique within the same domain participant, within the process or within the complete dds domain? If it is for example just unique within one domain participant, we can't use it for example as key in a map which could contain entities from multiple domain participants

The description of the TypeSupport::get_type_name operation currently states:

"This operation returns the default name for the data-type represented by the TypeSupport."

The problem is that the default name for the data-type is not specified anywhere. One logical choice would be the fully qualified type as per the IDL syntax. As an example org::omg::dds::demo::ShapeType.

If the specification does not clearly mandate the representation for the topic type interoperability may be hindered unless users explicitly override topic types.

This is very unfortunate and a critical issue that should be addressed ASAP.

The DDS v1.2 specification does not clearly specify the behaviour of redefining multiple times the same topic with different QoS. As a Topic represents a global assertion, having different applications associating different QoS with the same topic should be flagged as an error.

For keyed topics, the core set of read or take APIs support read|take, read|take_instance, and read|take_next_instance.

The corresponding set of API's for read or take with conditions only specified read|take_w_condition and read|take_next_instance_w_condition. The specification lacks the APIs for read|take_instance_w_condition.

Lack of these APIs deprives the user from the ability to read or take from a specific instance while limiting the sample set to specific conditions.

Section 7.l.3.6 of the DCPS spec should indicate what happens under the PRESENTATION=GROUP policy when different DataWriters in the group have different QoS settings. Whose settings are followed by the group? The most stringent? The least stringent? Group membership is dynamic, so the group members are not knows until each write() happens

The compatibility rules for the Presentation QosPolicy, specified in section 2.2.3.6 of the DDS Specification prevent a subscriber configured using GROUP access scope from simultaneously matching a publisher configured using GROUP access scope and a publisher configured using TOPIC or INSTANCE access scope.

Proposed Resolution:
The addition of a new boolean field called "use_highest_offered_access_scope" to Presentation QosPolicy.

This boolean is not propagated as part of the discovery information and remains local to the subscriber. Users configure the subscriber to the minimum accepted access scope. When the boolean field is set to true, the subscriber will provide the access_scope offered by the publisher as opposed to its own access_scope value.

For example: a subscriber wanted to provide GROUP access scope when matched with a GROUP order publisher and with a publisher providing INSTANCE access scope, will use INSTANCE access scope and set the user_highest_offered_access_scope boolean to true.

The logic of the PARTITION Qos applies separately to each DataReader/DataWriter and the propagation on the DCPS bultin Topics also happens along with each DataReader and DataWriter.

Despite this the PARTITION Qos can only be set on the Publisher/Subscriber which impact all the DataWriters/DataReaders they contain. To overcome this we have seen many users create a separate Publisher/Subscriber per DataWriter/DataReader which unnecessarily consumes resources and couples them.

The recommendation is to allow the PARTITION Qos to be set directly on the DataWriter and DataReader. This would not impact the behavior of partition matching. Just makes it more flexible to use.

A question is whether we should still allow the Publisher/Subscriber to have a PARTITION Qos. This may be desirable to avoid braking existing code. In this case we could interpret as a 'default" unless ta DataWriter/DataReader specifies it explicitly. This would make current applications work without changes.

Clarify what happens if coherent updates involve best-effors writers. Would missing one sample cause the whole set to be discarded?

Affects both TOPIC coherence and GROUP coherence if there are some best-efforts writers in the Publisher

I don't think that it is explicitly stated anywhere in this spec that each DataWriter and each DataReader maintains its own set of samples. Samples are not maintained by Publishers, Subscribers. It is implied in several places, e.g. the fact that RESOURCE_LIMITS applies to DataWriter and DataReader and not to Publisher and Subscriber. It took me a while to figure this out. It is possible for a Publisher to have more than one DataWriter with the same topic, and a Subscriber to have more than one DataReader with the same topic. The semantics of DataReader.take, for instance, are unclear unless it is understood that each DataReader has its own samples. Evidently a take operation on one DataReader does not disturb the samples of another DataReader with the same Publisher and Topic. Please clarify the specification in this regard. Figure 2-1 and accompanying text would be one place.

Context: DataReader.read operation Why are sample_states, view_states, and instance_states provided as separate parameters? Aren't they contained in sample_infos? More explanation required.

The Basic Service Mapping was included in the specification primarily to support implementations that did not support XTYPES. Now that most DDS support XTYPES this motivation is no longer there.

Having both a Basic Service Mapping and an Enhance Service Mapping creates significant complexity and ambiguity. It becomes another choice the user must make and another way implementations may not interoperate.

Furthermore when other specifications map to DDS Services, they must too make a choice of Service Mappings. Hence perpetuating complexity and interoperability issues.

The Enhanced Service Mapping has significant advantages in terms of performance, scalability, and type-system simplicity. Fundamentally it allows the use of the same types for request reply and RPC, any extra information is added in meta-data so that the types themselves are unpolluted. This is in-line with what other middleware technologies (e.g. JMS) does.

Therefore the most sensible thing is to deprecate the Basic Service Mapping.

noticed an inconsistency while I was reading the DDS spec (version 1.2) last night. My question relates to the following quality of service policy: DURABILITYSERVICE_POLICY_NAME

The pattern in all QoS names is:

*_QOS_POLICY_NAME, except for the DURABILITYSERVICE

The pattern in all QoS IDs is:

*_QOS_POLICY_ID

The DURABILITYSERVICE does adhere to the pattern/convention for Qos IDs:

DURABILITYSERVICE_QOS_POLICY_ID

But the does NOT adhere to the pattern/convention for Qos names. So, is there a typo in DURABILITYSERVICE_POLICY_NAME, i.e., should it be DURABILITYSERVICE_QOS_POLICY_NAME, or is the lacking of 'QOS' intentional?

Problem: The DDS specification (section 2.2.2.5.2.8) does not allow access to the DDS cache when the application wants to access data, but does not care about the order across Data Writers.

Proposed Resolution:
When using GROUP access scope, allow both access patterns and do not return PRECONDITION_NOT_MET
error code when called read, take, etc. without first called begin_access.

Note: This also allows portability for applications which do not care about the order across topics.

Found by: Fernando Crespo
Severity:

Problem:
OMG DDS spec (section 2.2.2.5.2.10) states that the sequence returned by
get_datareaders() will contain list containing each DataReader one or more times.
For example, if multiple consecutive samples in a group belong to the same DataReader
the DataReader is repeated in the list returned by get_datareaders().
Having to process each element, even when they belong to the same DataReader is
less performant.

Proposed Resolution:
Modify the specification to return one DataReader element, instead of a list where
a DataReader is repeated multiple times, when multiple subsequent samples belong to
the same DataReader. This allows for more optimized processing where the user calls
read/take until the return code is NO_DATA.

DDS4CCM adds support for qos xml files. There is no api in dds to create a dp/sub/pub/rd/wr with a qos given from the xml file. We propose to add the following methods to the DDS IDL to create dds entities with a qos xml profile.

    local interface DomainParticipant : Entity {
        Publisher create_publisher_with_profile(
            in string library_name,
            in string profile_name,
            in PublisherListener a_listener,
            in StatusMask mask);
        Subscriber create_subscriber_with_profile(
            in string library_name,
            in string profile_name,
            in SubscriberListener a_listener,
            in StatusMask mask);
        Topic create_topic_with_profile(
            in string topic_name,
            in string type_name,
            in string library_name,
            in string profile_name,
            in TopicListener a_listener,
            in StatusMask mask);
};


    local interface DomainParticipantFactory {
        DomainParticipant create_participant_with_profile(
            in DomainId_t domain_id,
            in string library_name,
            in string profile_name,
            in DomainParticipantListener a_listener,
            in StatusMask mask);
        ReturnCode_t set_default_participant_qos_with_profile(
            in string library_name,
            in string profile_name);
};


    local interface Publisher : Entity {
        DataWriter create_datawriter_with_profile(
            in Topic a_topic,
            in string library_name,
            in string probile_name,
            in DataWriterListener a_listener,
            in StatusMask mask);
};


    local interface Subscriber : Entity {
        DataReader create_datareader_with_profile(
            in TopicDescription a_topic,
            in string library_name,
            in string profile_name,
            in DataReaderListener a_listener,
            in StatusMask mask);
}; 

It seems that DDS vendors are implementing get_type_name of the TypeSupport interfaces differently. Some do it as static class method in C++, some as a regular method. The spec uses regular IDL, which gives the idea that it is a regular method needed a concrete TypeSupport instance, but I doubt whether that is intended

For write the DDS spec says:

The special value HANDLE_NIL can be used for the parameter handle. This indicates that the identity of the instance
should be automatically deduced from the instance_data (by means of the key).

The case which is not specified is the case where the handle is HANDLE_NIL, but they key we use hasn't been registered with dds yet, will DDS than return an error, or automatically register a new instance?

The DDS v2.1 introduces the concept of a ContentFilteredTopic in order to express filtering on a DataReder. The ContentFilteredTopic is a local entity that is not distributed via discovery. In addition content filters are already distributed as part of DataReader discovery.

As such it would be cleaner and more sensible to remove the ContentFilteredTopic and allow to express the filter directly through either DataReader QoS or as a Filter parameter (see DDS-PSM-Cxx for inspiration).

Since Topics are Entities, they can exist in a disabled state. Section 2.2.2.1.1.7 is insufficient to define what can (more importantly, can't) be done with a disabled Topic.
That section defines which operations "may be invoked on it", but more interesting for Topics are the passive uses of these objects as arguments to other operations.
In particular, it should be explicitly stated that a DataReader or Writer that references a disabled Topic (including, for readers, indirectly via ContentFilteredTopic or MultiTopic) cannot be enabled. In these cases, the enable() operation returns RETCODE_PRECONDITION_NOT_MET.

Examples:

• Selector from C++ PSM
• Cascading operations to set Qos policies qos.with().with().
• Dispatch on waitset and conditions (attach a function)
• "close" operation that is recursive and avoids having a handle to the factory.
  *

The second table in 2.2.4.1 (the one that starts with "SampleLostStatus") has confusing definitions of the "counts" in various plain communication status.

Certain "statuses" simply report events that occur within the Entities. Sample Lost is a good example of this. When a sample is lost, it's lost for good and not coming back. Therefore we expect total_count_change to be nonnegative. In this case the total_count definition is clear.

Other "status" are ways to report some aspect of the state of the Domain to the application. Inconsistent Topic is an example of this. Since remote Entities can change at any time, the count of inconsistent topics may decrease (for example, when a Topic owned by a remote Participant is deleted). For the "statuses" in this category, the wording of the definition of total_count (and perhaps other attributes) is confusing since it starts with "Total cumulative count..." just like the one for Sample Lost.

Problem:
The current specification provides no solution for the following two use-cases:
· A Volatile DataReader can receive data from a Transient or persistent DataWriter so it may also be interested in historical data. However a DataReader cannot receive historical data. Just making the DataReader Transient does not solve the problem because the DataReader may also be interested in volatile data.
· A Transient or Persistent DataReader may not be interested in historical data, there is no way to avoid receiving historical data. A DataReader may be e.g. Transient to avoid receiving data from volatile DataWriters, in addition there may be no interest in historical data.

Solution:
Separate the control of receiving historical data from the DataReaders durability interest. The DataReaders Durability interest will specify from which DataWriter it will accept data. A separate call will control (ask for) the retrieval of historical data.
Add the following method
ReturnCode_t get_historical_data(Duration_t max_wait)
And Transient and Persistent DataReaders should not automatically receive historical data. A consequence is that this invalidates the method
ReturnCode_t wait_for_historical_data(Duration_t max_wait).

Plain Communication Status structures may undergo multiple changes between the time the first event occurs and when the application reads/resets the Plain Communication Status. This results in loss of important data that DDS should make available to the application. It is more likely to occur when using the WaitSet/StatusCondition mechanism instead of Listeners, but may occur with Listeners depending on how the implementation determines when to invoke the Listener.

For example, an application creates a DataReader that uses Deadline QoS. In order to monitor for Deadline violations, the application gets the reader's StatusCondition and adds it to a WaitSet. If that Condition becomes active, the application invokes get_requested_deadline_missed_status to determine which instance experienced the deadline violation (using last_instance_handle). However, in the case that multiple instances have deadline violations since the last time status was checked (total_count_change > 1), the identity of all but the last of those instances is not available to the application.

This same concept applies to any of the uses of "last_*" in the Plain Communication Status structures.

Behavior of dispose is not specified for topics without key.
As per section "2.2.1.2.2 Overall Conceptual Model",. If no key is provided, the data set associated with the Topic is restricted to a single instance.

If data set is considered as a single instance than dispose of that instance shall be possible.

When expression parameters change, should any data stored in associated DataReaders be re-evaluated using the new parameters? Or do the DataReaders reflect the state of the parameters at the time the data was received?

If a writer disposes an instance that it never sent to a reader, should it still send the dispose to the reader?

In general sending it would cause an scalability problem. So it would be better not to.

However there are cases where it may be needed. For example if a Writer sets an alarm and a different writer that never created it wants to dispose it.

Perhaps this behavior something is something that should be configurable on the Reader or Writer.

RTPS 2.4 added support for GROUP ordered access and coherent access. As part of this effort, a number of restrictions and guidelines were identified that should be added to DDS in order to properly support these features.

The restrictions include:

• Writers shall not be created and/or deleted from the time a GROUP Publisher called begin_coherent_changes() to end_coherent_changes()
• Readers belonging to a subscriber with PRESENTATION access_scope=GROUP must all have the same value for DESTINATION_ORDER, RELIABILITY?, DURABILITY, OWNERSHIP
• Writers belonging to a Publisher with PRESENTATION access_scope=GROUP should have the same value for OWNERSHIP, DURABILITY, RELIABILITY?, DESTINATION_ORDER?
  • With OWNERSHIP: kind (i.e. all SHARED or all EXCLUSIVE) and in the case they are exclusive all Writers must have value of the the same OWNERSHIP_STRENGTH.

• All samples in the coherent set should have the same reception_timestamp and source_timestamp:
  • If access_scope = GROUP the reception and source timestamp are equal to that of the EndCoherentChanges sample.
  • If access_scope < GROUP the reception and source timestamp correspond to the ones from the last sample in the coherent set which may or may not be the EndCoherentChanges sample.

Guidelines:

• Adding a note for users that it may often be required to change the HISTORY kind/depth from KEEP_LAST,1. This is because a publisher that is quickly publishing coherent sets which update the same instances could very easily invalidate a coherent set that has not been fully delivered to the subscribers. Replacing a sample in history that is part of a coherent set invalidates that coherent set. It may be worth adding a callback that is called when a writer removes a coherent set from its queue
  • In general, writers that are part of a GROUP Publisher should be configured homogeneously.

RTPS 2.4 added support for GROUP ordered access and coherent access. It may be useful to consider adding some resource limits specifically associated with coherent sets.
For example, limiting the maximum number of samples that can be outstanding per DataReader and per Subscriber.

These resource limits would help to prevent a (potentially ill-intentioned) Writer from filling up the entire reader queue with a never-ending coherent set since the reader must store the coherent set until it is complete.

When using a GROUP ordered Subscriber, how do you access the samples in the order in which they are produced? The DDS1.4 specification says the following thing about this:.

"If the PRESENTATION QosPolicy of the Subscriber to which the DataReader belongs has the access_scope set to ‘GROUP.’ This operation should only be invoked inside a begin_access/end_access block. Otherwise it will return the error PRECONDITION_NOT_MET. Depending on the setting of the PRESENTATION QoS policy (see 2.2.3.6), the returned collection of DataReader objects may be a ‘set’ containing each DataReader at most once in no specified order, or a ‘list’ containing each DataReader one or more times in a specific order.

1. If PRESENTATION access_scope is INSTANCE or TOPIC the returned collection is a ‘set.’
2. If PRESENTATION access_scope is GROUP and ordered_access is set to TRUE, then the returned collection is a ‘list.’
   This difference is due to the fact that, in the second situation it is required to access samples belonging to different DataReader objects in a particular order. In this case, the application should process each DataReader in the same order it appears in the ‘list’ and read or take exactly one sample from each DataReader. The patterns that an application should use to access data is fully described in 2.2.2.5.1, Access to the data."

The big question here is: what happens when the user does not follow this scenario exactly? Here is a couple of potential deviations from the described scenario:

1. Reading more than one sample from every listed reader (i.e. use read/take with max_samples > 1)
   • We could state that no matter what the size of max_samples is, you get one sample at max.
2. Reading/Taking samples with different sample/view/instance state masks than passed to the get_datareaders() call.
3. Reading/Taking samples from a different reader than next one in the reader list.
4. you invoke get_datareaders() before having fully iterated through the previous reader list.

We should specify what happens if an application (intentionally or non-intentionally) does not follow the scenario laid out in the spec, or we should come up with an alternative reading mechanism that does not allow you stray off the correct path in these ways for example by introducing new function calls.

The DURABILITY Qos is defined as Request/Offered. If a DataWriter offers a kind, the DataReader 'request' kind must be 'less or equal'. Otherwise they will not match, for this comparison it is considered that
VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT.

This is not intuitive to users and does not match many of the use-cases observed in practice.

What users expect is for a DataWriter to configure its durability without impact on the matching (very much like HISTORY). The setting would just control whether the DataWriter keeps a local copy of the data for late joiners and whether it sends the data to the persistence services.

The reader in the other hand should simple state whether it wants "historical data" meaning data that was published before the reader joined the domain. This could just be a "boolean" or maybe a boolean plus some extra information that controls how much "historical data" to get.

If the DataWriter enabled durability then it would get the data that the DataWriters have on their "historical cache" that includes data from the Persistence services.

If a DataWriter set DURABILITY to TRANSIENT or PERSISTENT, then it would send its data to the PERSISTENCE services. It it was 'TRANSIENT LOCAL" then the Persistence service would not match the writer.

Ideally this could be done as an extension so it has minimal impact in current behavior or interoperabiity

DDS Security added information to the builtin-topic data.
Some if this information is generic and not specific to DDS Security. An example of this is DataTags. Even if those are things DDS Security can associate permissions with, the tags themselves are generic and would make sense for any DDS implementation.

The purpose of this issue is to identify those "generic" additions made by DDS Security and incorporate them to the DDS specification.

The DDS Security specification (see 7.2.5) added a DataTagQosPolicy defined as:

@extensibility(APPENDABLE)
struct Tag {
    string name;
    string value;
};

typedef sequence<Tag> TagSeq;

@extensibility(APPENDABLE)
struct DataTags {
    TagSeq tags;
};

typedef DataTags DataTagQosPolicy

This is actually a generic policy that does not require DDS Security. It makes sense even without security as a way to associate tags with DataWriters and DataReaders.

Therefore it would be better to move that definition to the DDS specification. This is a user-visible API that is expected to be explicitly set. If it is not part of the DDS API than applications would not be directly portable between DDS and DDS security.

The spec should also define values for DATATAG_QOS_POLICY_NAME and DATATAG_QOS_POLICY_ID. For example:

 const string DATATAG_QOS_POLICY_NAME = "DataTag";
 const QosPolicyId_t  DATATAG_QOS_POLICY_ID = 25;

Note that currently DDS-XTYPES defines IDs 23 and 24. Probably XTYPES should have used numbers in a different range so the IDs in DDS could remain contiguous.

See also DDS15-209.

DDS defines values of QosPolicyId_t from 0 to 22. Other specs (e.g. XTYPES) define additional values (23 and 24) and vendors potentially also define values.

To avoid confusion and collision DDS should allocate ranges for each of these. For example:
0-499 for DDS
500-999 for Other OMG specs
1000- for vendor extensions.

If we go with this proposal we need to file an issue with XTYPES to change the policy ID values to to the reserved range for "other specifications"

Problem:
For system management it is very useful that Entities can be identified by a logical application defined name. This attribute should ideal be set via the factory create call but if changing API's is not desired it can also be set via a QoS policy. This attribute should also be supported by the built-in Topics

Solution:
Introduction of a new Properties QoS that can be used for a name, but also for other things. The new QoS would contain a sequence of "properties" where each property is a pair of strings:
(property_name, property_value)
This Properties QoS can be used very much the same as the USER_DATA, but because each property is named, multiple things can be stored without conflicting with each other. This also provides an extensibility mechanism for the DDS spec. We can reserve the property-names with the prefix "DDS." To indicate "built-in" properties that should not be used by applications.
We can use this mechanism with the built-in property name "DDS.EntityName" to implement the name attribute.

2.2.3.4 DURABILITY

paragraph 5: "serviced" should be "service"

paragraph 8: "data-instances" should be "data-instance"

item #3: "longer that" should be "longer than"

last paragraph: "disposition" should be "disposal" or "dispose operation"

The IDL file describing the builtin topics consists of two parts:

• A section with #define statements where certain datatypes may be customized by the different vendors.
• A section where these customized datatypes are actually embedded in the builtin topic declarations.

All builtin topics contain a key field of type BuiltinTopicKey_t that is defined in the following way:

#define BUILTIN_TOPIC_KEY_TYPE_NATIVE long

module DDS {
    struct BuiltinTopicKey_t {
        BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3];
    };
};

This implies that vendors may specify part of the key (the array element type), but they may not specify it to be anything else than an array of three of those vendor specific datatypes.

Right now, different vendors have specified the BuiltinTopicKey_t in various different ways: some uses an array of 16 octets to directly reflect the RTPS GUID, but the official DDS spec does not allow for this.

In order to allow for these kinds of vendor specific customizations, the entire BuiltinTopicKey_t should be declared as a vendor specific #define statement.

As some context: this issue was filed in the RTPS RTF working group during the Dec 2017 San Fransisco OMG meeting. Basically the consensus was that indeed the builtin topic key type should be fully customizable. How this is exactly gonna be achieved was left to the DDS RTF working group.

How are dispose and unregister samples treated for DataReaders that use a ContentFilteredTopic or a QueryCondition?

Should these "lifecycle" notification samples pass all filters? Should the "key part" of the filter be considered when propagating these notifications?

The DDS-RTPS protocol supports directing samples to a specific DataReader. However there is no way to exercise this feature using standard DDS API.

The idea is to add an additional operation to the DataWriter allowing the specification of the destination DataReader. This could be a specific write_directed() operation or a more generic write_with_parameters() that allows additional parameters to be specified.

SQL grammar in BNF in clause B.2 limits topic names to the following characters: [A-Za-z0-9\-]+.

The DDS specification should add support for more characters. Some candidates are "/", ":", ".", "_". The latter is actually used in the DDS-XTYPES as a separator in the mapping of interfaces to request and reply topics.

We observe differences between DDS vendors related to begin/end_coherent_changes and presentation.coherent_access==true. The question is how begin_coherent_changes() should behave when presentation.coherent_access==false. Some vendors are silent and the operation just works, some return a RETCODE_ERROR saying begin_coherent_changes may only be called when presentation.coherent_access==true. To our idea the DDS spec should be precise so that users who separate code and qos (like DDS4CCM) do know what behavior they get

Currently there is no specification on the TypeSupport interface for an unregister_type operation as a companion to the register_type operation. This leads to variation between vendor implementations with respect to the lifecycle of type registrations. In the case of component-based architectural approaches it is desirable to be able to unload components to free resources. With no clear ability to unregister a type, it is not safe to unload component libraries while a container or manager of DDS infrastructure may still hold a reference to a no longer used type.

For portability & interoperability it is necessary to know what the valid syntax of topic names can be, including valid characters. Some vendors support characters like '.' '/', ':' while others don't.

The spec should make clear which characters are supported by all vendors

Note that Appendix B does include a TOPICNAME syntax, but this section appears only related to content filters it is not clear if this would limit a Topic name in general. In Appendix B it says:

TOPICNAME - A topic name is an identifier for a topic, and is defined as any series of characters ‘a’, ..., ‘z’, ‘A’, ..., ‘Z’, ‘0’, ..., ‘9’, ‘-’ but may not start with a digit.

This seems limiting and also the "-" seems like an odd choice or perhaps a typo. "_" would be a more natural choice...

Also it seems very restrictive to not allow things like "." or "/" or ":" given that large systems would want to organize their topic names and take advantage of this.

The DDS PIM DataReader read/take operations return a sequence. However there is no similar operation on the DataWriter.

This makes the API non-symmetric.

In fact the new DDS C++ PSM added a write() operation that takes a forward iterator. Which now is only available in this PSM and not the others.

This operation should be added to the PIM as it is a generic capability that should be available on all PSMs.

Context: "The act of taking a sample removes it from the DataReader so it cannot be ‘read’ or ‘taken’ again." See my earlier comment. Apparently if there are other DataReaders for the same Topic and the same Subscriber, their samples are not disturbed. Assuming this is true, it should be stated.

Context: "A Topic is identified by its name, which must be unique in the whole Domain." There is nothing in the description of create_topic that indicates that this constraint is enforced. Is it possible for multiple domain_participants to execute create_topic with the same name? What happens if they specify different types?

This issue was reported by email by Virginie Watine from THALES.

Assume a DW is TRANSIENT and a DR is VOLATILE.
According to the RxO policy attached to that QoS, they should match (all the other factors being OK). Is it correct?
(at least that is what the spec says)

But what are the first samples that are provided to the DR? I assume it receives only the ones that are produced after its creation (as opposed to a DR with TRANSIENT which receives also the ones that have been produced before its creation). Is it correct?
(that point is not explained in the spec – or at least is not easy to find)

The DDS 1.2 standard does not mention which IDL data types are permissible as
key fields for topic data types.

As the data types for keys, at least enumeration types and integral types
(octet/short/long etc.) should be permissible.
However, it would be desirable to also allow simple (non-array) typedefs
of these types.

Context: "If the kind is set to KEEP_ALL, then the Service will attempt to maintain and deliver all the values of the instance to existing subscribers. The resources that the Service can use to keep this history are limited by the settings of the RESOURCE_LIMITS QoS. If the limit is reached, then the behavior of the Service will depend on the RELIABILITY QoS. If the reliability kind is BEST_EFFORT, then the old values will be discarded." This violates the ordinary English meaning of KEEP_ALL. Can't the same effect be achieved by specifying KEEP_LAST with history_depth=max_samples_per_instance? If so, then KEEP_ALL should not be allowed for RELIABILITY=BEST_EFFORT.

Problem:
It is possible that a transaction needs to be canceled, for example because one of the participating writers gets blocked and finally stops while returning a timeout. This might lead to the situation in which you want to cancel all preceding writes as well.

Solution:
To be able to cancel such a transaction, we propose to add an additional operation like e.g. cancel_coherent_changes would then remove all samples that have already been written since the last begin_coherent_changes.

When PRESENTATION access_scope is GROUP samples need to e ordered across DataWriters. This is very hard/impossible if some writers use source_timestamp and others reception timestamp order

Propose that this is not allowed. If PRESENTATION access_scope is GROUP then all writers must have same ORDER. E.g. as writers are created if one is not consistent it should give an error

Problem:
From the OMG DDS specification the semantic of the liveliness of a reader instance is not clear, when it is exclusively owned by a writer. The LivelinessChangedStatus of the reader indicates how many active and inactive writers communicate with the reader. In case of exclusive ownership it is unclear whether only the reader sees the strongest writer as an active writer, or when it must see all available writers, since the reader will only receive samples from the strongest writer.

Solution:
Do we need to clarify this?

Problem:
It should be possible to obtain the "enabled" state of an Entity

Solution:
We propose to add a boolean operation to the Entity called something like is_enabled().

DDS uses IDL and defines its interface as regular interfaces, but these should all be local interfaces

Problem:
There is inconsistency in the spec: on page 2-24 there is a list of operations that is allowed when the DomainParticipant is in the disabled state. This list does not include any lookup operations. However, on page 2-14 there is also a list of operations which may be invoked when Entity has not yet been enabled, and here the 'lookup' operations are mentioned. So the questions are whether the DomainParticipant should be allowed to perform "find_topic" and "lookup_topicdescription" operations when it is in disabled state.

Solution:
Our proposal is that find_topic should not be allowed in this case, but lookup_topicdescription should be allowed. Also all delete operations including the delete_contained_entities should be allowed

For template meta programming as we are doing for the dds4ccm spec, it is needed to know at runtime time of the user program whether a topic has a key or not, because behaviour is dependent on that. we propose to add methods to the Topic to get its key fields

Problem:
In IDL, the operations on the TypeSupport interface are commented out: all operations are defined in its specialized sub-classes. That is strange, since all TypeSupport operations have a signature that is completely independent of this specific type.

Solution:
We propose to promote all these operations to the TypeSupport class itself, and thus to uncomment these operations in the TypeSupport interface.

The third paragraph of the DURABILITY section (2.1.3.4) describes the semantics that has to be provided by a durability service for TRANSIENT and PERSISTENT topics. Specifically, it states that given a Topic T with DURABILITY QoS set to TRANSIENT or PERSISTENT then the "built-in fictitious" DataReader and DataWriter used by the Durability Service to receive/distribute data have to be created with the same QoS T. Yet, nothing is said with respect to the role of the PARTITION QoS. Section 2.1.3.13 clearly states that:

"For a DataReader to see the changes made to an instance by a DataWriter, not only the Topic must match, but also they must share a common partition."

Thus based on the current specification the Durability Service DataReader and DataWriter would only match the applications DataReader and DataWriter that are in the default partition.