The last paragraph is a note, but is not is the note style
Proposal [THALES]
Correct the footprint

see below

In the final editing process, "native-language constructs" has become "native-language data-accessing constructs". However, the mentioned constructs are not only related to accessing the data (e.g., creation of an object)
Proposal [THALES]
Remove the extra "data-accessing"

see below

Ref-200 Figure_2_10_arrow_readcondition
The PIM indicates by means of the arrow pointing from ReadCondition to DataReader that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
Proposal: Fix by adding get_datareader() operation to the ReadCondition. This operation should take no arguments and return a DataReader
Ref-201 Figure_2_5_arrow_statuscondition
The PIM indicates by means of the arrow pointing from StatusCondition to Entity that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
Proposal: Fix by adding get_entity() to StatusCondition. This operation should take no arguments and return a Entity.
Ref-202 Figure_2_10_arrow_topicdescription
The PIM indicates by means of the arrow pointing from DataReader to TopicDescription that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
Proposal: Fix by adding get_topicdescription to DataReader. This operation should take no arguments and return a Topicdescription.
Ref-203 Figure_2_9_arrow_topic
The PIM indicates by means of the arrow pointing from DataWriter to Topic that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute).
Proposal: Fix by adding get_topic() to DataWriter. This operation should take no arguments and return a Topic.
Ref-227 Missing_navigation_operations
The PIM indicates by means of the arrow pointing from DataReader to Subscriber, from DataWriter to Publisher, and from DomainEntity to Participant that navigation is possible. However, the navigation is not present in the PSM (no operation, no attribute)
Proposal: Fix by adding DataReader::get_subscriber (no parameters, returns a Subscriber), DataWriter::get_publisher (no parameters, returns a Publisher), and the operations Publisher:: get_participant(), Subscriber::get_participant, and TopicDescription::get_participant() (these 3 operations should take no arguments and return a Participant). It is not needed to add get_participant to DataReader or DataWriter because it is possible to navigate to the subscriber/publisher and from there to the participant.

see below

Starting at "A DLRL object has at least one shared attribute..." (page 3-3), the whole section has been messed up during the final editing process; therefore, the content is no more understandable.
Proposal [THALES]
Restore the wording and footprint as it was in version V67 (the last Word one)

see below

DDS ISSUE# 2 Bad references
Ref-67 Bad_reference_to_SubscriberFactory
Sections 2.1.5, 2.1.6.2.1, and 2.1.6.2.2. Mention a SubscriberFactory. There is no SubscriberFactory. They should mention DomainParticipant. instead
Proposal: Replace SubscriberFactory with DomainParticipant in said sections.
Ref-71 Bad_reference_to_CORBA_PIM
Section 2.2.2. Says "The CORBA PIM is provided by means of the IDL that defines the interface an application can use to interact with the Service."
This should be: "The CORBA PSM ..."
Proposal: Replace as stated above
Ref-80 Bad_reference_to_appendixA
On page 2-21, 2-22, 2-28, 2-29, 2-54, 2-59 all the references to appendix A should be references to appendix B
Proposal: Replace as stated above

see below

Ref-66 Misplacing_of_key_in_builtin_topic_table
Section 2.1.5. Fields "key" with Topic DCPSPublication and DCPSSubscription are placed one row to high compared to the relating Topic. In other words, DCPSPublication and DCPSSubscription should be placed one row higher.
The thickness of the lines between the rows might suggest some relation between fields, but is implemented inconsequent.
Proposal: Correct table as described above.
Ref-103 Typo_on_section_2.1.2.5.2.8
3rd paragraph Says "... prior to calling any of the sample-accessing operations, namely: … on the DataWriter"
Should say "on the DataReader" instead of "on the DataWriter"
Proposal: Replace "DataWriter" with "DataReader" in said paragraph
Ref-105 Typo_on_section_2.1.3.11
Section 2.1.3.11 says "Assuming the STRENGTH policy allows it…"
Should say "Assuming the OWNERSHIP policy allows it…"
Proposal: Replace as stated above
Ref-115 Typo_consistent_use_of_term_publication
Section 2.1.2.2.1.15 says "The publication to ignore"… The parallel sentence in section 2.1.2.2.1.16 says the "The DataReader to ignore"…
These two sentences should be consistent
Proposal: Replace "publication" with DataWriter in 2.1.2.2.1.15
Ref-143 Typo_on_RELIABILITY_description
In Section 2.1.3, QoS table. The description of RELIABILITY in the last line it says "and whether a samples can be discarded from it." Should say "samples" instead of "a samples"
Proposal: Replace as stated above
Ref-145 Bad_reference_to_DCPSEntity
Section 2.1.3 Figure 15 Says DCPSEntity instead of Entity in one of the lines
Proposal: Replace as stated above
Ref-147 Typo_on_section_2.1.5
Section 2.1.5 third paragraph says: The last "r" in "get_datareader" is not using italics as it should within the sentence "The built-in DataReader objects can be retrieved by using the operation get_datareader, with the Subscriber and the topic name as parameters."
Proposal: Make the "r" italic.
Ref-207 Grammar_errors_on_secs_2.1.2.4_and_2.1.2.5
2.1.2.4.2.6: 2nd paragraph, 1st line: "one" should be "once" according to 2.1.2.1.1.7 this should be the case.
2.1.2.5.2.8: 3rd paragraph, 3rd line: "....on any DataWriter" should be "....on any DataReader"
2.1.2.5.3.8: Point 5, 3rd line: "....that is required that.... " should be "....that it is required that.....""
Proposal: Fix above 3 typos as stated above
Ref-221 Typo_on_section_2.1.4.4
2.1.4.4: First paragraph after the bullets:"... is done after
ininitial is at ion phase..." should be "... is done after initialization phase..."
Proposal: Fix as stated above
Ref-228 Typo_on_2.1.2.2.1.13
2.1.2.2.1.13 2nd paragraph, 4th line: "filed" should be "field"
Proposal: Fix as stated above

see below

The "which_added" operations on the collections were designed in the PIM so
that it is possible not to compute any result when the content of the
collection had been totally changed. This is not present in the IDL. *** Proposal [THALES]
change the operation to get a boolean result (true => the information is
returned in the out parameter; false => no information) instead of sending
the information as the result.

• • • Concrete changes
      IDL
      abstract valuetype ListBase : CollectionBase {
      boolean which_added (out LongSeq indexes);
      [instead of LongSeq which_added ();]
      ...
      abstract valuetype StrMapBase : CollectionBase {
      boolean which_added (out StringSeq keys);
      [instead of StrinSeq which_added ();]
      ...
      abstract valuetype IntMapBase : CollectionBase {
      boolean which_added (out LongSeq keys);
      [instead of LongSeq which_added ();]

see below

The module names in the IDL are very terse and not prefixed. In
this form they pose a high risk of a name collision with any other,
even user-written, IDL module. I would suggest to prefix the module
names as explained in the IDL Style Guide (ab/98-06-03). The "Cos"
prefix would be adequate. This means to change for example
"module DDS" to "module CosDDS", or even to a more intuitive
"module CosDataDistributionService" for the benefit of the user.
I think non of today's systems has a severe name limitation
anymore.

Further email narrowed the proposal to "CosDDS".

Proposed action: No Change

Both RTI and THALES feel that the change significantly affect users that
have started developing applications using the API. Our companies have
invested significantly in the API and a change this late would make us
lose a lot of credibility and may really upset some customers. In the
case of RTI this includes documentation that has been in-use by
customers over the last 6 months.

In our respective markets there is a lot of people using C and C++ with
compilers that don't support name-spaces so this change affects a very
visible part of the API, namely the prefix of every function. The change
may appear small but it may actually have big impact if we consider
user-acceptance.

Furthermore, the use of the "Cos" prefix may be misleading as the
Data-Distribution Service was designed so it would be implementable
without an object service.

closed no change

The is_composition operation is described in the PIM, but is not in the IDL.
It concerns the valuettype RefRelation, ListRelatrion, IntMapRelation, and
StrMapRelation.

• • • Proposal
      add the following operation
      boolean is_composition(); on those valuetypes

see below

The resolution of issue 6816 added operation to get and set default QoS on all the entity factories except for the DomainParticipantFactory. This was an omission as this factory also needs to provide these operation such that DomainParticipant entities can also be created using default QoS.
The operation lookup_participant is defined in the PIM (section 2.1.2.2.2) and does not appear in the PSM
Furthermore, it would be desirable to have some utility constants in the IDL that can be used to indicate to the factory that default QoS should be used to construct an entity. This avoids having to explicitly get the default QoS in the case the application does not want to change any of the defaults. Helper constants can also be added for the specific case of constructing DataReader and DataWriter entities when the application wishes to indicate that the QoS should be obtaining by modifying the default values with the ones defined by the Topic Qos

see below

Issue [THALES]
As notification_scope has been removed from the ObjectHome (cf. issue ref-1049), it is necessary to pass the information whether the modification of objects inside a Selection should be appreciated only on the object basis, or on the object + its contained objects basis
clarification is requested regarding when the SelectionListener is activated
Proposal [THALES]
add a parameter concerns_contained when the Selection is created and add this characteristic in the selection attributes
add a paragraph to specify when the Selection Listener is activated
in SelectionListener::on_object_out, the ObjectRoot may no more exist, therefore passing the ObjectReference is better
Concrete changes
in IDL
local interface Selection

;
local interface SelectionListener

;
in section 3.1.6.3.7 Selection
in the table, attribute list, add the following entry (as third attribute)
concerns_contained boolean
in the following text, starting with "It has the following attributes:"
add the following text at the end of the second bullet:
"; it is given at Selection creation time(cf. ObjectHome::create_selection)"
add a bullet in third position, with the following content:
"a boolean concerns_contained that indicates whether the Selection considers the modification of one of its members based on its content only (FALSE) or based on it content or the content of its contained objects (TRUE); it is given at Selection creation time(cf. ObjectHome::create_selection);"
add at the end of the section, the following paragraph:
"The SelectionListener is activated when the composition of the Selection is modified or when one of its members is modified. A member can be considered as modified, either only when it is itself modified or when itself or one of its contained objects is modifie (depending on the value of concerns_contained). Modifications in the Selection are considered with respects to the state of the Selection last time it was examined, i.e.:
add one bullet with the following text:
" at each incoming updates processing if autro_refresh is TRUE;"
add a second bullet with the following text:
"at each explicit call to refresh, if auto-refresh is FALSE."

see below

The resolution of issue 6833 added USER_DATA QoS to Topic.
However this name overlaps with the USER_DATA on the DataWriter and DataReader and prevents an application from using both at the same time.

**PROPOSAL**
Rename USER_DATA on Topic to be TOPIC_DATA.
This involves adding a TOPIC_DATA QoS that concerns Topic, DataReader and DataWriter
Add topic_data as a field in the DCPSTopic, DCPSPublication and DCPSSubscription tables describing the built-in topics in section 2.1.5, page 2-90.

see below

Section 2.1.3 "Supported QoS" is missing a subsection that describes the OWNERSHIP_STRENGH QoS policy

***Proposal ***
Add section 2.1.3.7 with the text:

2.1.2.3.7 OWNERSHIP_STRENGH
This QoS policy should be used in combination with the OWNERSHIP policy. It only applies to the situation case where OWNERSHIP kind is set to EXCLUSIVE.
The value of the OWNERSHIP_STRENGTH is used to determine the ownership of a data-instance (identified by the key). The arbitration is performed by the DataReader. The rules used to perform the arbitration are described in Section 2.1.3.6.2 .

see below

Section 2.1.2.5.3 of the specification does not clearly state that the
data_value and the sample_info sequences returned by the read* and
take* operations must be of the same length and are in one-to-one
correspondence

Furthermore, the specification does not describe what the element of
the DataSeq should be when the SampleInfo states that the
lifecycle_state is DISPOSED

Same issue when the lifecycle_state is NO_WRITERS

These should be clarified

**PROPOSAL**

This must be rephrased in accordance with the proposal in Ref-84.

State in section 2.1.2.5.3 that both sequences are of the same length
and in one-to-one correspondence

State that when the that when the liveness_lifecycle is DISPOSED
(NO_WRITERS or EXPLICIT) the last sample for the instance, that is the
one with instance_rank==0 has no corresponding data

see below

In the current specification, the applications are fully responsible
for the resource usage. Applications have means to detect when
lifecycles end and resources can be freed. However even if
applications are to be written correctly not all cases are covered and
some situations potential produce garbage, that is memory that remains
in use and never reclaimed.

The following are potential scenarios:

Instances become disposed but the application does not 'take' the
sample and therefore does not allow the middleware to end the
lifecycle and remove the state regarding the instance

Instances that no longer have any "active" writers and consequently
get no more samples.

Even if the application 'takes' the disposed instance or instances
with no writers it is not always possible for the middleware to
reclaim the resources. This can occur in two cases; in case of the
service keeping Transient and Persistent data and in case of
incomplete MultiTopic samples. In both cases an immediate removal of
samples is not desirable but eventually the samples should be removed

On the one hand deleting the instances immediately will potentially
cause problems since late coming readers may require the disposed
instances, e.g. reallocating consumers requiring disposed instances to
finish interrupted cleanup actions or MultiTopics joining Topics with
different lifecycles.

On the other hand the disposed instances cannot be kept
indefinitely. Doing this will eventually flood the system, especially
for Topics with increasing key-values.

The solution is to keep them for a certain duration and then reclaim
the resources the question is how long this duration should be?

Note that, in general, just because a sample has been disposed the
middleware cannot reclaim all the resources on it either on the writer
side or on the reader side. For the middleware to reclaim resources it
is necessary that the instance is also unregistered; otherwise
disposing would automatically relinquish ownership which is not the
desired behavior.

This applies both to the writer side, the reader side, and/or the
transient/persistent durability service.

On the writer side it is therefore clear. Resources are only fully
reclaimed when the instance is unregistered.

So the tricky issue is how to handle the case where an instance has no
writers, whether it had been disposed or not, whether there are
samples in the queue or not. Nominally we notify the application of
this event by some means (see Issue #84). The application should then
take the samples.

One approach would be for the middleware to keep some resources around
for a certain duration (DISPOSE_LIFESPAN) in case this was just a
transient situation and the instance appears again. This treats the
DISPOSED_NO_WRITERS similarly to the DISPOSED_EXPLICIT

**PROPOSAL**

Add a new QoS on the DataReader called NO_WRITERS_LIFESPAN with a
single Duration_t field "duration". It is mutable with a default
value equal to DURATION_INFINITY. This represents the duration for
which the DataReader should keep the knowledge of an instance once it
detects it has NO_WRITERS.

After the instance has no writers the middleware is not required to
keep the information about the instance any longer than the
NO_WRITERS_LIFESPAN. The implication is that if an instance becomes
DISPOSED_NO_WRITERS and the application does not take the instance for
a time that exceeds the NO_WRITERS LIFESPAN the application could miss
the fact that the instance has DISPOSED and has no writers.

see below

Ref-84 Lifecycle_state_refactor

The precise interpretation and representation of the lifecycle and
sample states in the specification is not clear.

Figure 2-11 is not easy to interpret as it refers to "observable"
lifecycles rather than representing some internal state that the
application accesses.

Several issues are left open such as

Whether what happens if in the sample history of a single instance are
new, modified, and deleted samples (i.e. the instance was disposed and
then created again before the reader accessed it). An additional
question is then whether the read/take will return samples belonging
to multiple "generations" of the instance.

How can an application determine that as a result of a single
read/take operation multiple samples of the same instance appear. This
may be important because the processing a new/modified sample may
depend on the number of samples the application has for that instance.

Also the representation of the instance_state as an enumeration:
NEW/MODIFIED/DELETED/NO_WRITERS is not natural. If this represents the
state of the instance, then the instance can be simultaneously
MODIFIED and DELETED; it can be MODIFIED and have no writers,
etc. That is logically these are not mutually exclusive

**PROPOSAL**

Change the description in section 2.1.2.5.1 and representation
lifecycle as described below.

Replace the lifecycle_state with the following two variables (flags)

observation_lifecycle =

liveness_lifecycle =

Define DISPOSED as the union (DISPOSED_EXPLICIT | DISPOSED_NO_WRITERS)

The observation_lifecycle and liveness_lifecycle are independent. All
combinations are possible. So the lifecycle may be simultaneously NEW
& DISPOSED_EXPLICIT, NOT_NEW & ALIVE, etc.

All the samples in the history of an instance have the same
"lyfecycles" states. Each time a sample is received (or a loss of
liveliness on a remote DataWriter is detected) the liveness_lifecycle
may change. If it changes it changes for all samples belonging to the
same instance.

If an instance was DISPOSED (either DISPOSED_EXPLICIT or
DISPOSED_NO_WRITERS) and a samplefor that instance is received, the
liveness_lifecycle of the instance changes to ALIVE.

If a sample is received for a DataWriter, indicating that the ser has
called "dispose" for that instance then the liveness_lifecycle of the
instance changes to DISPOSED_EXPLICIT.

If the infrastructure detects the loss of liveness of a DataWriter for
the instance and this is the only DataWriter writing the instance
known to the reader then the liveness_lifecycle of the instance
changes to DISPOSED_NO_WRITERS

Each time the liveliness of an instance changes from ALIVE to
DISPOSED_EXPLICIT an internal count maintained per instance
(disposed_explicit_count) is incremented. Each time the liveliness of
an instance changes from ALIVE to DISPOSED_NO_WRITERS an internal
count maintained per instance (disposed_no_writers_count) is
incremented.

The observation_lifecycle and liveness_lifecycle as well as the
disposed_explicit_count and disposed_no_writers_count appear in the
SampleInfo returned when the application reads/takes samples. This
counters are from the perpective of the DataReader and start at 0 when
the liveness_lifecycle is NEW

Each time the application reads or takes samples, all returned samples
for any one instance have the same observation_lifecycle and
liveness_lifecycle. They represents the "snapshot" of the
corresponding values for the instance taken at the time the data is
read or taken.

The disposed_explicit_count and disposed_no_writers_count in
SampleInfo are not the same. On all samples. They represent the number
of lifecycles of each kind that the instance had gone through at the
time the sample stored into the history queue. The application can use
this to distinguish samples belonging to different generations. In
addition the SampleInfo contains an additional filed. The
"instance_rank" that specifies how many samples for the same instance
follow in the sequence retuned as part of the read/take. This helps
the application anticipate that more samples for the same instance
follow. The last sample for the instance returned will always have a
instance_rank==0

In addition the SampleInfo contains an additional filed. The
"generation_rank" that specifies the generation to which the sample
belongs relative to the generations

The observation_lifecycle, liveness_lifecycle, disposed_explicit_count
and disposed_no_writers can be used as in the expressions used for the
purposes of making a Query.

Figure 2-11 should be updated to reflect the state-transitions
described above.

Both the read and take operations affect the
observation_lifecycle. The first time the application reads/takes
samples for an instance the observation_lifecycle will be NEW. After
the observation_lifecycle will be NOT_NEW.

Once the application reads/takes samples with the liveness_lifecycle
DISPOSED (either EXPLICIT or NO_WRITERS), the observation_lifecycle is
'reset' and if new samples are received for that instance the
observation_lifecycle will be set to NEW again.

see below

Ref-121 Add_a_return_loan_operation_to_datareader

For high-performance it is desirable to use a zero-copy API on the
receive side where the middleware can "loan" buffers to the
application on the "read" or "take" operations.

However the use of "zero-copy" requires a mechanism for the
application to indicate that it no longer needs access to the "loaned
buffers"

One possibility would be to an operation DataReader::finish or
DataReader::return_loan that takes the SampleData and SampleInfo
sequences as parameter and indicates to the middleware that the
application is no longer accessing the buffers in the corresponding
sequences.

Another possibility would be to add a separate API for read/take

**PROPOSAL**

No concrete proposal yet

see below

Could be that the result of the read is many samples (100000s). This
would be bad for the application.

**PROPOSAL**

No concrete proposal as it would be hard to represent in IDL but it
would be nice if such API was offered.

see below

Ref-74 Refactor_the_api_used_to_access_samples

The read() and take() operations return a "one-dimensional" array of
samples.

For the case where the PRESENTATION.access_scope==BY_INSTANCE and
either HISTORY.kind == KEEP_ALL or HISTORY.depth > 1 it is desirable
that the application can easily access all the samples that correspond
to one instance versus the samples that correspond to other
instances. For this purpose a 2-dimensional array (or sequence) where
a is preferable. That would allow for example to determine easily how
many samples are for each instance (before examining all) and also
easily examine the "first" or "last" sample of each instance without
navigating though all the other instances

What we would like is something like:

struct FooSample

;

typedef sequence<FooSample> FooSampleSeq;

read(out FooSampleSeq sample_seq);

typedef sequence<FooSampleSeq>; FooSampleCollatedSeq;

read_collated(out FooSampleCollatedSeq collated_seq);

Data would be then accessed as

sample_seq[i]->data;

Or else as

collated_seq[k][I]->data

However t is not clear how to map this to the IDL PSM.

**PROPOSAL**

No concrete proposal as it would be hard to represent in IDL but it
would be nice if such API was offered.

see below

Related to 112

The specification does not mention whether the DISPOSED samples count
towards the RESOURCE_LIMITS (max samples and such)

Although this detail unspecified, it is something that would become
observable to the user if, for some reason, an application does not
"take" disposed samples.

**PROPOSAL**

State that these samples don't count towards the limits because they
do not have "data" associated with it. Moreover in view of Ref-84
there can be at most one such SampleInfo per instance so the
worst-case needed resources are small and can be taken into account by
the implementation

duplicate

Currently the specified mapping is rather strict with respects to the mapping between the DLRLOid and the DCPS topic keys. When an existing DCPS schema is reused, more flexibility would be desirable
In particular, there exist cases when there are no DCPS keys at all (should correspond to a singleton class)
In some circumstances, the indication of the class name while needed in the main topic (to guess what is the type of the corresponding object) is not needed in the relations to objects of that type

see below

Issue [THALES]:
Selection could be slightly enhanced, by providing to the filter the fact if the object was previously a member.
proposal [THALES]
carry the fact that the object was previously part of the selection to the filter so that it may return quicker the result when appropriate
Concrete changes
IDL
enum MembershipState

;

local interface ObjectFilter

;
in section 3.1.6.3.8 ObjectFilter
in the table, add a parameter to the check_object operation by adding the following entry:
membership_state enum MembershipState
in the following text, add the following text to the bullet
[check ... (check_object);] this method is called with s first parameter the object to be checked and as second parameter an indication whether the object previously passed the filter (membership_state); this last parameter (which is actually an enumeration with three possible values - UNDEFINED_MEMBERSHIP, ALREADY_MEMBER and NOT_MEMBER) is useful when the ObjectFilter is attached to a Selection to allow the writing of optimized filters.
ref-1051: New definition for Selections (clarification)
Issue [THALES]
As notification_scope has been removed from the ObjectHome (cf. issue ref-1049), it is necessary to pass the information whether the modification of objects inside a Selection should be appreciated only on the object basis, or on the object + its contained objects basis
clarification is requested regarding when the SelectionListener is activated
Proposal [THALES]
add a parameter concerns_contained when the Selection is created and add this characteristic in the selection attributes
add a paragraph to specify when the Selection Listener is activated
in SelectionListener::on_object_out, the ObjectRoot may no more exist, therefore passing the ObjectReference is better
Concrete changes
in IDL
local interface Selection

;
local interface SelectionListener

;
in section 3.1.6.3.7 Selection
in the table, attribute list, add the following entry (as third attribute)
concerns_contained boolean
in the following text, starting with "It has the following attributes:"
add the following text at the end of the second bullet:
"; it is given at Selection creation time(cf. ObjectHome::create_selection)"
add a bullet in third position, with the following content:
"a boolean concerns_contained that indicates whether the Selection considers the modification of one of its members based on its content only (FALSE) or based on it content or the content of its contained objects (TRUE); it is given at Selection creation time(cf. ObjectHome::create_selection);"
add at the end of the section, the following paragraph:
"The SelectionListener is activated when the composition of the Selection is modified or when one of its members is modified. A member can be considered as modified, either only when it is itself modified or when itself or one of its contained objects is modifie (depending on the value of concerns_contained). Modifications in the Selection are considered with respects to the state of the Selection last time it was examined, i.e.:
add one bullet with the following text:
" at each incoming updates processing if autro_refresh is TRUE;"
add a second bullet with the following text:
"at each explicit call to refresh, if auto-refresh is FALSE."

see below

Issue [THALES]
These operations are error-prone when there are called by the developer.
Proposal [THALES]
suppress them and specify that the internal cleaning of modifications is performed after the last call to listeners
Concerns the interfaces
ObjectRoot
CollectionBase (was CollectionOperations)
RefRelation (was ReferenceOperations)
Concrete changes:
IDL
suppress the following operations
ObjectRoot::clean_modified
CollectionBase::clean_modified
RefRelation::clean_modified
in section 3.1.6.3.11 ObjectRoot
in the table, suppress the 2 lines that describe the operation clean_modified
in the following list of methods (starting with "it offers methods to") suppress the last bullet
in section 3.1.6.3.13 Reference
in the table, suppress the 2 lines that describe the operation clean_modified
in the following list of methods (starting with "it offers methods to") suppress the last bullet
in section 3.1.6.3.14 Collection
in the table, suppress the 2 lines that describe the operation clean_modified
in the following list of methods (starting with "it offers methods to") suppress the last bullet
in section 3.1.6.4.1 General Scenario
in the last bullet, suppress the end of the sentence "(if not already done)"
Finally [..] of the updated objects are cleaned.

see below

Ref-161 Behavior_of_register_type

The specification does not say what happens if the application locally
tries to define the same "type_name" via register_type

The case where a different DataType is being "registered" with a name
that was already used should clearly fail

The case where the same DataType is registered again with the same
name could either fail or be idempotent.

**PROPOSAL**

State in 2.1.2.3.6 that it is a pre-condition that the same name has
not already been used to register a different type. In case this is
attempted the register_type() operation shall return
PRECONDITION_ERROR

State in 2.1.2.3.6 the documentation that it is OK to re-register the
same DataType again with the same type_name. In this case the
operation is idempotent and returns OK.

see below

159 Rename_the_interface_DataType

The name DataType used in the PSM and IDL to refer to the interface
with the "register_type"operation from which the FooDataType derives
for each user-data type 'Foo' is causing confusion.

People think that the FooDataType actually represents the type of the
objects being propagated. In reality the type is 'Foo' and FooDataType
just provides the support to intgrate 'Foo' with the middleware

**PROPOSAL**

Rename DataType to TypeSupport. FooDataType to FooTypeSupport

see below

Ref-152 General_use_of_RETCODE_NOT_IMPLEMENTED

Many operations that can return may need the additional ReturnCode_t
NOT_IMPLEMENTED don't explicitly say so.

**PROPOSAL**

In section 2.1.1.1 add ReturnCode_t NOT_IMPLEMENTED to the list of
codes any functions may return, with the provision that it only
applies to functions that are pert of some optional compliant point.

see below

Ref-138 CORBA_PSM_OR_OMG_IDL_PSM

Document refers to the PSM as a "CORBA" PSM. Wouldn't it be more
appropriate to call it the OMG IDL PSM

**PROPOSAL**

Change to references to OMG IDL

see below

Ref-146 Bad_arrow_direction_in_figure_19

Section 2.1.4.4 Figure 2-20

The arrows between the BLOCKED and UNBLOCKED states are backwards

**PROPOSAL**

Reverse directions in Figure 2-20

see below

Section 2.1.2.3.4. Says It says "filter_expression" should be
"subscription_expression" in the sentence "The expression_parameters
attribute is a sequence of strings that give values to the
'parameters' (i.e. "%n" tokens) in the subscription_expression. The
number of supplied parameters must fit with the requested values in
the filter_expression (i.e. the number of %n tokens)."

**PROPOSAL**

Replace "filter_expression" with subscription_expression in Section
2.1.2.3.4

see below

Ref-??? Missing_fields_in_builtin_topics

It appears that definition of built-in topics in section 2.1.5 is
missing some fields

Related to Ref-68

**PROPOSAL**

Add the missing fields

Define a concrete type for the BuiltinTopicKey_t. Make it long[3]

see below

Ref-159 Rename_the_interface_DataType

The name DataType used in the PSM and IDL to refer to the interface
with the "register_type"operation from which the FooDataType derives
for each user-data type 'Foo' is causing confusion.

People think that the FooDataType actually represents the type of the
objects being propagated. In reality the type is 'Foo' and FooDataType
just provides the support to intgrate 'Foo' with the middleware

**PROPOSAL**

Rename DataType to TypeSupport. FooDataType to FooTypeSupport

See issue 6848 for disposition – duplicate

Issue [THALES]
For footprint reasons an ObjectHome is designated by its index in the Cache. For convenience, the index should be an attribute of the ObjectHome
Proposal [THALES]
add the index readonly attribute
return the allocated index when the home is registered
add an operation to retrieve the home based on the index and homogeneise names of find operations
Concrete changes:
IDL
interface ObjectHome {
...
readonly attribute unsigned long registration_index;
...
interface Cache {
...
unsigned long register_home (
in ObjectHome a_home)
raises (
BadHomeDefinition);
ObjectHome find_home_by_name (
in ClassName class_name)
raises (
BadParameter);
ObjectHome find_home_by_index (
in unsigned long index)
raises (
BadParameter);
...
In section 3.1.6.3.3 Cache
In the table
Change the return type for register_home operation from "void" to "integer"
Change the name of "find_home" to "find_home_by_name"
add the following entry:
find_home_by_index ObjectHome
integer registration_index
In the following text, starting with "It offers methods"
first bullet: add at the end "this method returns the index under which the ObjectHome is registered by the Cache;"
second bullet:change to "to retrieve an already registered ObjectHome, based on its name (find_home_by_name) or based on its index of registration (find_home_by_index)
in section 3.1.6.2.3.5 ObjectHome
in the table
at the end of the attribute list, add the following entry
registration_index integer
in the following text, in the list starting by "The public attributes gives"
add a last bullet "the index under which the ObjectHome has been registered by the Cache (cf. Cache::register_home)
Correct the UML diagram accordingly

see below

There is a need that the application can provide the oid of an object at creation time
That characteristic should be provided on a class basis.

see below

***Ref-137 Bad_reference_to_Condition

Section 2.1.2.1.7.1 says "StatusCondition" when it should say
"Condition"

**PROPOSAL** Replace StatusCondition with Condition in 2.1.2.1.7.1

see below

Ref-117 Deadlines_accumulate

Some people have been confused reading the specification with regards
to the "total" counts and whether they accumulate.

For example, whether the "deadline count" accumulates missed
deadlines. That is, each deadline-time period that passes without an
instance being written increments the deadline count even if the
application does not have time to read the status

**PROPOSAL**

State this more explicitly on section 2.1.4.1

see below

Ref-116 Inconsistent_use_of_instance_in_datawriter_api

Currently Section 2.1.2.5.1 mentions the function dispose_instance
which does not exist.

A broader issue is that we have functions called
register_instance/unregister_instance, but other functions that also
apply to an instance (dispose, write, dispose_w_timestamp,
write_w_timestamp, etc.) do not have "instance" in their name... This
can lead to some confusion

**PROPOSAL**

Rename dispose_instance to dispose

Fix the sequence chart in figure 2.1.6.1

Leave the register_instance alone

see below

Issue [THALES]
All private members should be named consistently starting by m_
Concerns m_ref and m_refs in Relation
Proposal [THALES]
change the names
Concrete changes
IDL
valuetype RefRelation {
private ObjectReference m_ref;
[instead ref]
valuetype ListRelation : ListBase {
private ObjectReferenceSeq m_refs;
[instead refs]
valuetype IntMapRelation : StrMapBase {
...
private ItemSeq m_refs;
[instead refs]
valuetype IntMapRelation : StrMapBase {
...
private ItemSeq m_refs;
[instead refs]

see below

Issue [THALES]
Just a long seems too small to express a DLRLOid
proposal [THALES]
Change to a structure with 2 longs, one meant to identify the creator of the Oid and one local to this creator.
Concrete changes
IDL
struct DLRLOid

;
[instead typedef long DLRLOid]

see below

Issue [THALES]
return of is_modified() on a newly created object is unspecified
Proposal [THALES]
should return false
concerns the text
Concrete change
in section 3.1.6.3.11 ObjectRoot
in the text after the table, starting with "it offers methods to:"
last bullet, add the following sentence at the end "in case the object is newly created, this operation returns false."

see below

Ref-72 Creation_of_waitset_and_guardcondition

The DDS spec already says they are not created from a factory because
they are intended to be base classes that will be extended by
application-defined classes. This makes them similar to the Listener
interfaces.

However it would be desirable to be more explicit regarding this

**PROPOSAL**

State in the PSM section that WaitSet GuardCondition are to be
implemented as classes in the native language that can be created
using the "new" operator natural in the PSM. Furthermore, they should
have at least a constructor that takes no arguments so that
applications can be portable across implementations of the DDS spec.

see below

The built-in Topics are defined in the PIM but not in the PSM.

**PROPOSAL**

Add the definition to the IDL PSM in section 2.2.3

include structures containing the fields in the built-in topics
described in the table in section 2.1.5

See issue 6862 for disposition – duplicate

Issue [THALES]
Currently there is only one ObjectHome and one Cache Listeners. This has been considered by users as fairly limited and as several selections are allowed, unjustified
Proposal [THALES]
Allow several listeners.
Precise the triggering order
Concrete changes
IDL
local interface Selection {
...
SelectionListener set_listener (
in SelectionListener listener);
[instead attach_listener in the commented out section]
...
local interface Cache {
...
readonly attribute CacheListenerSeq listeners;
[instead readonly attribute CacheListener listener]
...
void detach_listener (
in CacheListener listener);
[instead no parameter]
...
local interface ObjectHome {
...
readonly attribute ObjectListenerSeq listeners;
[instead readonly attribute ObjectListener listener]
...
void detach_listener (
in ObjectListener listener);
[instead no parameter]
...
in section 3.1.6.3.3 Cache
in the table
list of attributes replace the entry for listener by the following
listeners CacheListener []
list of operations, replace the entry for detach_listener by the following
detach_listener void
listener CacheListener
in section 3.1.6.3.5 ObjectHome
in the table
list of attributes replace the entry for listener by the following
listeners ObjectListener []
list of operations, correct the entry for attach_listener by the following (ObjectListener instead of Listener)
attach_listener void
listener ObjectListener
list of operations, replace the entry for detach_listener by the following
detach_listener void
listener ObjectListener
in section 3.1.6.3.7 Selection
in the table, change the entries for attach_listener and detach_listener to only one operation set_listener, as follows:
set_listener SelectionListener
listener SelectionListener
in the following text, in the list starting with "it offers the methods to:"
change the first bullet to:
"set the listener (set_listener) that will be triggered when the composition of the selection changes as well as if one of its members is modified; set_listener returns the previously set listener if any; set_listener, called with a NULL parameter discards the current listener."
in section 3.1.6.4.1 General Scenario
In the list starting with "This set of updates is managed as follows"
change the first bullet to:
"First, all the CacheListener::start_updates operations are triggered; the order in which these listeners are triggered is not specified"
change the last bullet to:
"Finally all the CacheListener::end_updates operations are triggered and the modification state of the object are cleaned; the order in which these listeners are triggered is not specified."
in section 3.1.6.4.2 Object Creation
In the list
change the first bullet to:
"First, the ObjectListener suitable to that object are searched and their on_object_created operations triggered; the search follows the inheritance structure starting from the more specific ObjectHome (e.g., FooHome, for an object typed Foo) to ObjectRoot. The search is stopped when all on_object_created operations at one level return true; inside one level the triggering order is not specified."
in section 3.1.6.4.3 ObjectModification
In the list
change the last bullet to:
"Then, the ObjectListener suitable to that object are searched and their on_object_modified operations triggered; the search follows the inheritance structure starting from the more specific ObjectHome (e.g., FooHome, for an object typed Foo) to ObjectRoot. The search is stopped when all on_object_modified operations at one level return true; inside one level the triggering order is not specified."
in section 3.1.6.4.4 ObjectDeletion
In the list
change the last bullet to:
"the ObjectListener suitable to that object are searched and their on_object_deleted operations triggered; the search follows the inheritance structure starting from the more specific ObjectHome (e.g., FooHome, for an object typed Foo) to ObjectRoot. The search is stopped when all on_object_deleted operations at one level return true; inside one level the triggering order is not specified."

see below

ref-1041: clone + deref
Issue [THALES]
For performance, it seems good to offer a combined operation clone + deref that returns the instantiated cell instead the ObjectReference
Proposal [THALES]
Add such a method on ObjectRoot and also in the implied IDL
Concrete changes:
IDL
ObjectRoot {
...
ObjectRoot clone_object(
in CacheAccess access,
in ObjectScope scope,
in RelatedObjectDepth depth)
raises (
ReadOnlyMode,
AlreadyClonedInWriteMode);
Foo {
...
Foo clone_foo(
in CacheAccess access,
in ObjectScope scope,
in ReletedObjectDepth depth)
raises (
ReadOnlyMode,
AlreadyClonedInWriteMode);
in section 3.1.6.3.11 ObjectRoot
in the table, add the clone_object operation, by adding the following:
clone_object ObjectRoot
access CacheAccess
scope ObjectScope
depth integer
in the following text, in the list starting with "it offers methods to":
insert a second bullet, with the following contents:
"clone and instantiate the object in the same operation (clone_object), this operations takes the same parameters as the previous one, but returns an ObjectRoot instead of an ObjectReference; it corresponds exactly to the sequence of clone followed by CacheAccess::deref on the reference returned by the clone operation;"
in section 3.1.6.5.1 Read Mode
item #2, change "(ObjectRoot::clone)" to "(ObjectRoot::clone or clone_object)"
in section 3.1.6.5.2 Write Mode
item #2, change "(ObjectRoot::clone)" to "(ObjectRoot::clone or clone_object)"

see below

ref-1049: New definition for ObjectListener
Issue [THALES]
When a contained object is modified, it can be difficult to get the information in the ObjectListener
In all cases, getting the old value seems useful in certain cases,
As first parameter, the ObjectReference is more appropriate tah the ObjectRoot, for the object may not be instanciated; in addition, this simplifies because it is no more mandatory to generate the implied FooListener.
Whether the notification concerns the object or the object + its contained object should be set on a Listener basis, rather than on the ObjectHome basis.

see below

ref-1046: delete_clone
Issue [THALES]
Useful to remove a clone from a CacheAccess in addition to the deletion of all the clones.
Proposal [THALES]
add an operation on CacheAccess to delete a clone
should concern the object itself + all its components, but not the related objects (regardless to what was the clone request)
Concrete changes
IDL
local interface CacheAccess {
...
void delete_clone(
in ObjectReference ref);
...
in section 3.1.6.3.2 CacheAccess
in the table, after the purge operation, insert the delete_clone operation, by insetring the following entries:
delete_clone void
ref ObjectReference
in the following text,
introduce a bullet, before the last one, with the following content:
"alternatively, the copy of one object and all its attached contained objects can be detached from the CacheAccess (delete_clone);"

see below

In section 2.2.3 (IDL) the entities DomainParticipant, Topic,
Publisher, DataWriter, Subscriber, and DataReader are missing the
get_listener/set_listener operations.

Those operation are all present in the PIM.

**PROPOSAL**

Add said operations to the IDL to match the PIM

see below

Section 2.1.2.1.8. The enabled_statuses attribute for a GuardCondition
is incorrect since a GuardCondition does not have any relationship
with status conditions.

**PROPOSAL**

Remove the attribute from section 2.1.2.1.8

see below

Section 2.1.2.4.2. FooDataWriter class table. The unregister_instance
method is specified to return InstanceHandle_t.

The return type should be ReturnCode_t conform the IDL PSM.

**PROPOSAL**

Correct section 2.1.2.4.2 to match the IDL file.

see below

Section 2.1.2.3.3 in the ContentFilteredTopic class table, there is
the attribute related_topic. This attribute is missing in the IDL PSM.

**PROPOSAL**

Correct the IDL to match the PIM.

see below

Section 2.1.2.1.1. Method get_statuscondition. According to the IDL
file, this method is replaced by two other methods named
create_statuscondition and delete_statuscondition. Which of the two is
right?

The IDL is incorrect. Given that there is a single statuscondition
associated with an Entity having only a get_statuscondition operation
and no delete_statuscondition.

**PROPOSAL**

Correct the IDL. Replace the create_statuscondition and
delete_statuscondition in the IDL with get_statuscondition as
desxribed in the PIM.

see below

Section 2.1.2.2.3. DomainParticipantListener Interface table: The
operation on_requested_deadline_missed_qos is mentioned instead of
on_requested_deadline_missed.

**PROPOSAL**

Correct section 2.1.2.2.3

see below

Ref-114 Behavior_of_instances_when_deleting_datawriter

What happens when an application deletes a datawriter? Do all
registered instances become unregistered? What about samples that may
have been written but not propagated to remote readers?

There are two possibilities:

Approch1 behave as if the application had crashed with regards to the
readers. The application should have been explicit about the contained
entities (e.g. unregister/dispose) before deleting the writer.

Approach2 handle it as any deletion of a container entity. It is a
pre-condition error if it has any registered instances and the entity
is not deleted. But also we provide helper operations on the
DataWriter to unregister_all_instances() and dispose_all_instances().

**PROPOSAL**

Use Approach2. Its more explicit and less error-prone.

Also say that the infrastructure is not required to immediately
release the resources before returning from the delete but can keep
them around for a while until is properly has a chance to clean up its
state, inform remote nodes, etc.

see below

Ref-101 Move_sample_lost_status_to_datareader

Section 2.1.4.2 shows in a table that SAMPLE_LOST_STATUS is on the
Subscriber. It would make more sense to have it on the Datareader. It
is not as useful to the application to know that samples have been
lost for DataReaders belonging to the Subscriber as it would be to
know which DataReaders they affected.

When we first specified this it was thought that it would be hard to
implement as a status on the DataReader because, given that the
samples are lost, it would not be clear which DataReader they
affect. As it turns out the anticipated implementation difficulties
are not there.

**PROPOSAL**

Remove the SAMPLE_LOST_STATUS from the status of the Subscriber and
add it to that of the DataReader in the table in 2.1.4.2

Also modify the PIM in section 2.1.2.5.2 and the PSM in section 2.2.3
moving the get_sample_lost_status operation from Subscriber to
DataReader

see below

Section 2.1.4.1. The Table that describes the statuses and the meaning
of the attributes has an incorrect description of the
"total_count_change"

Currently it talks about topic names, not counts

**PROPOSAL**

In section 2.1.4.1 replace the text "The type of the last topic
discovered..."

With: "The incremental number of inconsistent topics discovered since
the last time the listener was called or the status was read"

see below

The specification does not state clearly whether the TIME_BASED_FILTER
applies on a per-instance basis or for the whole topic.

It should probably be per instance but it should be said explicitly.

**PROPOSAL**

Add the clarification to section 2.1.3.8. State that the filter
applier per instence, that is, the reader is requested not to receive
more than one sample per minimum_separation period for each instance

see below

Section 2.1.3 on the QoS table. The description of the
TIME_BASED_FILTER QoS says"

"The setting of this QoS is incompatible with RELIABILITY policy set
to ALL"

First there is no such setting for reliability policy. It intended to
say it is incompatible with RELIABILITY 'RELIABLE' and HISTORY
'KEEP_ALL'.

However it is unclear why it is necessary introduce such
incompatibility. It would be better to interpret the meaning of
RELIABLE and KEEP_ALL to mean that the application desires that all
samples that pass whichever filters have been specified are propagated
reliably and kept by the middleware until they can be delivered to the
DataReader. In other words, the RELIABILITY and HISTORY policies apply
after the "filter-type" policies apply. The filters determine what is
of interest, the reliability whether samples lost by the transport
should be retried and the HISTORY whether to keep old values that have
not been delivered to the application once a new value
exist. Interpreted this way all combination of the above policies are
sensical. This approach also extends to the ContentFilteredTopic

**PROPOSAL**

Remove that comment from the TIME_BASED_FILTER QoS

Add a third paragraph to section 2.1.3.8 that explains that it is
indeed possible to specify RELIABILITY RELIABLE, and a HISTORY
KEEP_ALL and still set a TIME_BASED_FILTER. The paragraph would say:

The setting of a TIME_BASED_FILTER, that is, the selection of a
minimum_separation with a value greater than zero is compatible with
all settings of the HISTORY and RELIABILITY QoS. The TIME_BASED_FILTER
specifies the samples that are of interest to the DataReader. The
HISTORY and RELIABILITY affect the behavior of the middleware with
respect to the samples that have been determined to be of interest to
the DataReader, that is, they apply after the TIME_BASED_FILTER has
been applied.

Specify that that if the reliability is RELIABLE then in steady-state
it should behave as-if the last sample passes the
TIME_BASED_FILTER. In other words, in steady state the last sample
should eventually become available to the receiver.

see below

Ref-208 Latency_budget_description

Section 2.1.3 has a wrong description of LATENCY BUDGET. It says that
it specifies the acceptable delay from production time until 'it is
received by subscribing application' which might suggest that it
includes the time an application might wait until actually reading the
data.

Rather it should say that it specifies the acceptable delay from
production time until the data is inserted in application-cache and
the application is notified of the fact.

**PROPOSAL**

Update the description. In the table to say that "it specifies the
acceptable delay from production time until the data is inserted in
application-cache and the application is notified of the fact"

see below

Ref-204 Entity_table_get_statuscondition_return_not_enabled

Section 2.1.2.1.1, 1st paragraph under the Entity table: In the list
of methods which cannot return a "NOT_ENABLED", the
"get_statuscondition" method is not mentioned.

This is inconsistent with the text in 2.1.2.1.1.7 where it says that
get_statuscondition may be called even if the entity is not enabled.

**PROPOSAL**

Remove the sentence 2.1.2.1.1, 1st paragraph "All operation except for
... return the value NOT_ENABLED" as this is already described in
2.1.2.1.1.7

see below

Ref-90 Initial_data_from_transient_or_persistent_data

The specification mentions that if the DURABILITY is set to TRANSIENT
or PERSISTENT a newly appearing DataReader would be able to get some
amount of history data.

However the precise semantics of this are not clear. For example is
the application allows to receive information as soon as the Reader is
active (perhaps from active writers) even before the historical data
has been received?

It would be desirable to offer the application some control about how
to initialize the reader when it first joins the system.

**PROPOSAL**

Introduce an operation DataReader:: get_historical_data(in Duration_t
max_time_to_wait);

This operation will block for a maximum of max_time_to_wait until the
system gets the initial data.

Introduce the ReturnCode_t "TIMEOUT" to section 2.1.1.1.

State that the get_historical_data operation will return OK if all the
initial data has been received. Otherwise it will return TIMEOUT if
the system cannot ensure that all historical data has been received.

see below

Ref-136 Missing_ENUMERATION_from_expression_syntax

ENUMERATION missing from terminals of expression for
Query/Filters/Multitopic on the appendix

**PROPOSAL**

Add the following to the grammars in Appendix B and C.

Under the rule for Parameter ::=

Add the ENUMERATION as a terminal analogous to the INTEGER value.

In the table describing the terminals, explain that the ENUMERATION is
named using the identifier for the enumerated member. Either using the
plain label or if there is conflict using the
EnumerationTypeName::EnumerationLabel

see below

Ref-131 Module_name_dcps

The specification contains two top-level module names 'DCPS' and
'DLRL' it is desirable to not have so many modules. It will complicate
the C mapping and and also weaken the "brand"

We have verified that there are no naming clashes between the two
modules so they can be combined

**PROPOSAL**

In section 2.2.3 replace the module name from 'DCPS' to 'DDS'

In section 3.2.1.2 replace the module name from 'DLRL to 'DDS'

see below

The description of the DURABILITY Qos in section 2.1.3 is ambiguous
with regards to the TRANSIENT kind. It would appear that there are in
fact two kinds:

The first interpretation "TRANSIENT_LOCAL" would have the durability
tied to the liveliness of the DataWriter..

The second interpretation "TRANSIENT_GLOBAL would tie the durability
to the fact that some "durability servide" in the system is still
executing.

It should be explained which of these interpretations is meant.

**PROPOSAL**

Modify the QoS table in 2.1.3 to separate the TRANSIENT durability
into two kinds: TRANSIENT_LOCAL and TRANSIENT.

TRANSIENT_LOCAL ties the durability to the liveliness of the
writer. This is the mandatory level described in Appendix A.

TRANSIENT allows the durability to survive the liveliness of the
DataWriter. Explain this kinds in the table and in section 2.1.3.2

see below

In Section 2.1.3, QoS table

Clarify the LIVELINESS "MANUAL_BY_PARTICIPANT". What it says is
correct. But its getting some people confused.

It says:

"The Service will assume that as long as at least one Entity within
the domain has asserted its liveliness the Entity is also alive."

Some people are mistakenly understanding this as:

"...at least one Entity within the domain has asserted its liveliness
the domain is also alive."?

So maybe its best to say:

"The Service will assume that as long as at least one Entity within
the domain has asserted its liveliness the other Entities in the
domain are also alive."

**PROPOSAL**

Replace as stated above

see below

In order to support the BY_SOURCE_TIMESTAMP setting the DataWriter
needs to take appropriate actions (e.g. embed timestamps). Therefore
the DESTINATION_ORDER QoS should follow the same request/offered
pattern other QoSs do.

**PROPOSAL**

Modify the QoS table in section 2.1.3 and add DataWriter as in the
"Concerns" column for DESTINATION_ORDER. Also replace with "Yes" in
the "RxO" (request/offered) column.

Add a paragraph to section 2.1.3.11 stating the request/offered
compatibility as follows:

The value offered is considered compatible with the value requested if
and only if the inequality "offered kind >= requested kind" evaluates
to 'TRUE'. For the purposes of this inequality, the values of
DESTINATION_ORDER kind are considered ordered such that
BY_DESTINATION_TIMESTAMP < BY_SOURCE_TIMESTAMP.

see below

In case where the OWNERSHIP QoS is EXCLUSIVE, the specification
describes that ownership is lost if the DataWriter loses its
liveliness. However it does not describe whether it loses the
ownership if it misses its deadline with regards to writing the
instance.

If this case is left unspecified the most natural interpretations
would be that the DataWriter does indeed maintain ownership even when
it is missing its deadlines. This seems undesirable.

We do not want a DataWriter that has promised to write samples within
a pre-stated deadline and fails that contract to retain ownership of
an instance and by so doing starve prevent other writers from writing
the instance and therefore starve the reader from data. The
underlying goal is to make the system robust to faults that affect a
single entity.

**PROPOSAL**

Modify section 2.1.3.6.2 (EXCLUSIVE kind) to reflect this. This
affects several paragraphs:

• • First paragraph

Replace: The owner is determined by selecting the DataWriter with the
highest value of the strength that is currently "alive" as defined by
the LIVELINESS QoS policy.

With: The owner is determined by selecting the DataWriter with the
highest value of the strength that is both "alive" as defined by the
LIVELINESS QoS policy and has not violated its DEADLINE contract with
regards to the data-instance.

• • First paragraph

After "Ownership can therefore change as a result of (a) ..."

Add a forth case (d) a deadline with regards to the instance that is
missed by the DataWriter that owns the instance.

• • Fifth paragraph

Modify "It is also required that the owner remains the same until
there is a change in strength, liveliness, or a new DataWriter with
higher strength modifies the instance."

To: "It is also required that the owner remains the same until there
is a change in strength or liveliness, the owner misses a deadline on
the instance, or a new DataWriter with higher strength modifies the
instance."

see below

In Section 2.1.3, QoS table. Section on DURABILITY setting.

Says compatible only if requested kind > offered kind. Should have
said requested >= offered. Same in PRESENTATION

**PROPOSAL**

Replace "requested kind > offered kind" with "requested kind >=
offered kind"

see below

The QoS table in section 2.1.3 specifies default values for some of
the QoS. Others however are unspecified.

To be consistent we should provide some default value for all
QoS. Meaning if the user never specified the QoS (assuming the
Topic_qos_as_default_for_datareader_or_datawriter_qos issue is
resolved) then we should specify what the behavior should be

**PROPOSAL**

Complete the table in section 2.1.3 with the following values:

USER_DATA: empty sequence (zero-sized)

DURABILITY: VOLATILE

PRESENTATION: access_scope=INSTANCE, coherent_access=FALSE,
ordered_access=FALSE

DEADLINE: (already specified)

LATENCY_BUDGET: says "zero" but that is not really meaningful so
perhaps INFINITE?

OWNERSHIP: (already specified)

OWNERSHIP_STRENGTH: zero

LIVELINESS: (already specified)

TIME_BASED_FILTER: (already specified)

PARTITION: empty sequence (zero length)

RELIABILITY: (already specified)

DESTINATION_ORDER: BY_RECEPTION_TIMESTAMP

HISTORY: (already specified)

RESOURCE_LIMITS: (already specified)

see below

In section 2.1.3.4 it is unclear whether the service is expected to
check compatibilities between DEADLINE and TIME_BASED_FILTER
policies. For example, a DataWriter offering a DEADLINE period smaller
than a DataReaders TIME_BASED_FILTER is bound to lead to problems with
reliable transmission.

Another example is a DataReader which has a DEADLINE period smaller
than the TIME_BASED_FILTER period.

**PROPOSAL**

State that DataReader which has a DEADLINE period smaller than the
TIME_BASED_FILTER period results on INCONSISTENT_POLICY.

see below

In section 2.1.3 the explanation of the table mentions: "The QosPolicy
objects that need to be set in a compatible manner at the publisher
end are indicated by the setting of the RxO property" This suggests an
asymmetry between publishers and subscribers. It is not true that
compatibility of policy objects is entirely the responsibility of the
publisher, is it?

**PROPOSAL**

In said sentence replace "at the publisher end" with "between the
publisher and subscriber ends".

see below

Some use-cases would benefit from having USER_DATA also on Topic.

**PROPOSAL**

Add TOPIC_DATA to the TopicQoS with the same definition as the
USER_DATA. The initial value should be an empty sequence

Add topic_data as a field in the DCPSTopic in the table describing the
built-in topics in section 2.1.5, page 2-90.

see below

In Section 2.1.3, QoS table states USER_DATA is immutable.

Many of the use-cases of the USER_DATA require the application to be
able to change the USER_DATA dynamically.

**PROPOSAL**

Make USER_DATA mutable in section 2.1.3.

see below

The PSM/IDL does not provide the means for an application to specify
an invalid time (e.g. in the SampleInfo)

**PROPOSAL**

Add the following constant to the IDL:

Timestamp t TIMESTAMP_INVALID =

see below

Ref-33 Specification_of_infinite_duration

The PSM/IDL does not provide the means for an application to specify
an infinite duration (e.g as a timeout)

**PROPOSAL**

Add the following constant to the IDL:

Duration_t DURATION_INFINITE =

see below

The "enable"operation was added in support of DLRL. However if the
application is not using DLRL it is often inconvenient to have to
explicitly "enable" each entity before using it.

**PROPOSAL**

Add a QoS to the DomainParticipant, Publisher and Subscriber called
ENTITY_CREATION_SETTINGS. This QoS contains the Boolean
"create_enabled". If this Boolean is set to "TRUE" then the entities
created by the factory will be automatically enabled (i.e. the factory
will call the enable() before returning the entity).

Specify that the default value of this setting is TRUE.

Specify that this QoS is mutable

This affects sections 2.1.3, and 2.2.3

see below

Ref-30 Topic_enable_semantics

In section 2.1.2.1.1.7 it is not clear what is the precise semantics
of the "enable" on a Topic are? Can the same or another node see it
(by means of "lookup_topic") a Topic that has not been enabled?

Similarly can the TopicListener be invoked before the Topic is
enabled. It appear undesirable since the QoS may still change.

**PROPOSAL**

Clarify that the Topic is not accessible by means of "lookup" neither
locally not globally until it has been enabled.

Also clarify that the TopicListener will only be called after the
Topic is enabled.

see below

Ref-38 Duplicate_domainId_to_create_participant

The specification does not clarify the behavior of
DomainParticipantFactory create_participant when the domainId
specified is already used.

**PROPOSAL**

Return a HANDLE_NIL in that case.

Also add a lookup_participant method to DomainParticipantFactory with
a parameter of type DomainId_t. to allow finding a pre-exising
DomainParticipant.

see below

The data available status becomes TRUE when data is available, but
under what condition does it become FALSE again?

According the specification when data is taken, but does this only
apply to the object that is accessed? Or do the status values of other
objects that become untrue as a result of the take action also need to
be changed?

Example: A reader with 3 queries, data arrives and the status of the
reader and all queries become TRUE. The data is taken via the reader,
do the status values of the queries become FALSE?

**PROPOSAL**

Add the following clarifications to section 2.1.4.4

DataReader::take() and DataReader::read() changes the status of the
queries that are no longer true after the 'take'. Since 'take' removes
the data from the service so its no longer there it would make little
sense for the status to remain enabled.

In other words the same way that arrival of data may change the 'data
available status' of any query, so would the 'taking' or 'reading' of
data potentially affect all queries.

Note that this does not mean that waitesets that were attached to the
query will not be woken up. This is an implementation issue. Once the
query status changes to 'enabled' it may wake up the attached waitset,
transitioning to 'not-enabled' does not necessarily 'unwakeup' the
waitset since this operation is in general not possible. The
consequence is that the application may be woken up and not see any
active conditions. This is unavoidable if multiple threads are
concurrently taking data.

see below

Currently, the lookup_topic method returns a type Topic. Why does it
not return a type TopicDescription? In that case, it could also be
used to search for ContentFilteredTopics and MultiTopics.

**PROPOSAL**

Change prototype lookup_topic to return TopicDescription.

Change name from lookup_topic to lookup_topicdescription

Specify that lookup_topicdescription will also find
ContentFilteredTopic and MultiTopic

This affects sections 2.1.2.2.1.11, and 2.2.3.

see below

Ref-43 TopicDescription _name_attribute

In section 2.1.2.3 TopicDescription has an attribute called "name.
However the IDL is inconsistent. TopicDescription does not have the
"name" attribute, instead Topic has the name and the other derived
classes (ContentFilteredTopic and MultiTopic) do not have a name

In the IDL specification the name specified by the TopicDescription
but instead only by the Topic.

It makes sense to have the name on TopicDescription as in the PIM such
that all kinds of TopicDescription entities can be locally accessed by
means of "lookup_topic".

**PROPOSAL**

Fix the PIM IDL file to match the PSM.

see below

In section 2.1.2.5.2 the order of parameters in get_datareaders is
(LifecycleState, SampleState) is inconsistent with the order in the
methods which is (SampleState, LifecycleState)

**PROPOSAL**

Change parameter order to (SampleState, LifecycleState) This affects
both the PIM (section 2.1.2.5.2) and the IDL PSM

see below

2.1.2.2.3: In the "on_requested_deadline_missed" method, the second
parameter is of type "RequestedIncompatibleQosStatus" instead of type
"RequestedDeadlineMissedStatus"

**PROPOSAL**

Fix section 2.1.2.2.3. parameter type should be
RequestedDeadlineMissedStatus

see below

Page 2-68 the field in QoS RESOURCE_LIMITS is called
max_instance_samples. In the IDL (page 2-104) says
max_samples_per_instance

**PROPOSAL**

Change table in 2-68 replace the two references to
max_samples_per_instance

see below

The communication statuses LIVELINESS_LOST and LIVELINESS_CHANGED do
not have a corresponding PSM IDL StatusKind constant definitions

**PROPOSAL**

Correct the IDL PSM. Add said definitions consistently with PIM.

see below

Section 2.2.2. The PSM IDL StatusKind constant definitions
OFFERED_INSTANCE_DEADLINE_MISSED_STATUS and
REQUESTED_INSTANCE_DEADLINE_MISSED_STATUS are not mentioned in the PIM
and do not have a corresponding Status class either.

**PROPOSAL**

Correct PIM and add said statuses to section 2.1.4.1.

see below

Section 2.1.2.5.3 FooDataReader class table, operation read and
take. In the table, lifecycle_states and sample_states parameters are
reversed with respect to IDL PSM.

**PROPOSAL**

Correct section 2.1.2.5.3.

see below

Ref-01 Listener_waitset_triggering

The specification does not make clear whether listeners and waitsets
are awaken once per "event" that causes a change of status (implying a
queue of events) or are they just awaken once when the status changes.

**PROPOSAL**

Clarify that there is no implied "queueing". The listeners and
waitsets are enabled based on the status change but not necessarily
called/signaled multiple times. This clarification should appear in
section 2.1.4.

see below

Section 2.2.3 IDL. TopicQos, DataWriterQos, DataReaderQos have field
called delay_laxity should be latency_budget according to the PIM

**PROPOSAL**

Change the IDL to match the PIM by renaming delay_laxity to
latency_budget

see below

Section 2.1.2.5.3 (DataReader and FooDataReader class table),
operations read_w_condition and take_w_condition. In the IDL file, the
sample_info parameter is of type SampleInfo instead of SampleInfoSeq.

**PROPOSAL** Correct the IDL PSM. sample_info parameter should be of
type SampleInfoSeq.

see below

In section 2.1.2.5.2, subscriber class table, operation
notify_datareaders void. In the IDL file this method has two
parameters: LifecycleStateMask and SampleStateMask

**PROPOSAL**

Correct the IDL PSM. Remove the parameters in the IDL file.

see below

Section 2.1.3. According to the QosPolicy table, USER_DATA does not
concern Publisher and Subscriber entities. The IDL PSM however has
UserDataQosPolicy as a member of both the PublisherQos and
SubscriberQos structures.

**PROPOSAL**

Correct the PSM. USER_DATA remove USER_DATA from Publisher and
Subscriber

see below

Attribute/accessor for SampleRejectedStatus missing from 2.1.2.5.3

**PROPOSAL**

Add the get_xxx accesor to the DataReader class

see below

Section 2.1.2.5.3. FooDataReader class table. The get_key_value
method is named get_key in the IDL PSM.

**PROPOSAL**

Correct the IDL PSM. Method should be named get_key_value

see below

Section 2.1.2.4.2. DataWriter class table. The get_key_value method
is named get_key in the IDL PSM.

**PROPOSAL**

Correct the IDL PSM. Method should be named get_key_value

see below