Issues for Data Distribution Service Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 6685: DDS editorial issues
Issue 6686: Bad references
Issue 6687: Missing operations to allow the navigation described in the PIM
Issue 6705: ref-1001: section 3.1.1 (editorial
Issue 6706: ref-1002: section 3.1.2.1 (editorial
Issue 6707: ref-1003: Section 3.1.3.2 (editorial)
Issue 6708: ref-1004: Section 3.1.3.3 Metamodel (clarification)
Issue 6709: ref-1005: figure 3.2 (editorial)
Issue 6710: ref-1006: Page 3.11 (editorial)
Issue 6711: ref-1007: Section 3.1.6.3.4 CacheListener (editorial)
Issue 6712: ref-1008: Bad annex reference (editorial)
Issue 6713: ref-1009: Section 3.2.3.2 IDL Model description of the example
Issue 6714: ref-1010: Section 3.2.3.3 XML Model Tags of the example
Issue 6715: ref-1011: Section 3.2.3.3 Introduction to figure 3.9 (editorial)
Issue 6716: ref-1012: Section 3.2.3.3 Simplified XML of the example)
Issue 6717: ref-1013: Section 3.1.6.3.9 Table for ObjectQuery (editorial)
Issue 6718: ref-1014: Page 3-10, figure 3-2 min_topic (editorial)
Issue 6719: ref-1015: Page 3-62 manual edition (editorial)
Issue 6720: ref-1016: Page 3-65 t2 (editorial)
Issue 6721: ref-1017: Section 3.1.4.4.2 topic (editorial
Issue 6722: ref-1018: Name of the methods for ObjectListener (editorial)
Issue 6723: ref-1019: Name of the ObjectRoot::clone method (editorial)
Issue 6729: Additional_communication_paradigms
Issue 6730: Attributes_on_a_topic_description
Issue 6731: Extension_to_the_partition_qos
Issue 6735: Transactional_reliability Issue
Issue 6736: Writer_notification_of_delivery_failure Issue
Issue 6738: Navigation_of_connectivity_information Issue
Issue 6739: Additional_qos_DATA_PRIORITY Issue
Issue 6740: Additional_qos_LIFESPAN Issue
Issue 6743: Make_USER_DATA_an_array_and_mutable Issue
Issue 6744: CacheFactory::find_cache (addition
Issue 6745: : Attributes and operations directly set on valuetypes
Issue 6746: Names of the ObjectRoot attributes
Issue 6747: Depth of cloning (addition)
Issue 6748: CacheAccess operations (documentation)
Issue 6749: CacheAccess::delete_access (editorial
Issue 6750: CacheAccess::deref (clarification)
Issue 6751: stringSeq and longSeq (editorial)
Issue 6752: ObjectHome::get_topic_name (editorial
Issue 6753: ObjectHome::get_all_topic_names (addition
Issue 6754: Operations on collections of objects (addition
Issue 6755: Name of ObjectLink (consistency)
Issue 6756: Obtaining the DomainParticipantFactory
Issue 6757: Potential problems in PSM mappings
Issue 6758: Naming_of_attribute_getter_operations
Issue 6759: Ref-62 Return_type_of_set_query_operations
Issue 6760: Delete dependencies and semantics
Issue 6761: Ref-20 Semantics_of_factory_delete_methods
Issue 6762: Ref-87 Clarify_Topic_deletion_as_local_concept
Issue 6763: Ref-151 No_locally_duplicate_topics
Issue 6764: Ref-22 Automatic_deletion_of_contained_entities
Issue 6765: Ref-15 Behavior_on_deletion_from_wrong_factory
Issue 6766: Single waitset attached to condition
Issue 6767: Entity specialization of set/get qos/listener
Issue 6768: Ref-36 Entity_specialization_set_get_qos
Issue 6769: Inconsistencies between PIM and PSM/IDL
Issue 6770: Ref-39 Entity_specialization_set_get_qos
Issue 6771: Ref-28 IDL_entity_get_statuscondition
Issue 6772: Ref-34 Incorrect_guard_condition_enabled_statuses
Issue 6773: Ref-37 Entity_ specialization_set_get_listener_in_idl
Issue 6774: Ref-42 DomainParticipantListener_on_requested
Issue 6775: Ref-46 ContentFilteredTopic_related_topic
Issue 6776: Ref-48 FooDataWriter_unregister_instance
Issue 6777: Ref-49 DataWriter_get_key
Issue 6778: Ref-57 FooDataReader_get_key
Issue 6779: Ref-56 Subscriber_notify_datareaders_parameters
Issue 6780: Ref-58 DataReader_read_take_w_condition
Issue 6781: Ref-59 FooDataReader_read_take_parameter_order
Issue 6782: Ref-70 Missing_deadline_statuskind_from_pim
Issue 6783: Ref-79 Missing_StatusKind_liveliness_idl_constants
Issue 6784: Ref-88 Inconsistent_naming_PIM_IDL_instance_samples
Issue 6785: Ref-205 On_requested_deadline_missed_paramtype
Issue 6786: Ref-126 Inconsistent_parameter_order_to_get_datareaders
Issue 6787: Ref-135 Missing_accessor_for_SampleRejectedStatus
Issue 6788: Ref-63 QoS_USER_DATA_on_Publisher_and_Subscriber
Issue 6789: Ref-229 IDL_rename_publisher_laxity_w_latency_budget
Issue 6790: Clarification of listener invocation and waitset signaling
Issue 6791: Ref-02 Data_Available_status_transition
Issue 6792: Duplicate use of domainId
Issue 6793: Use of Topic versus TopicDescription
Issue 6794: Ref-40 Name_and_return_type_of_lookup_topic
Issue 6795: Reason and use of enable
Issue 6796: Ref-31 Reason_and_use_of_enabled
Issue 6797: DDS ISSUE# 14] Helper addition to the IDL
Issue 6798: Ref-118 Introduce_TIME_INVALID_constant
Issue 6799: Ref-102 Addition_of time_related_constants
Issue 6800: DDS ISSUE# 15] Semantics of register and unregister instance
Issue 6801: DDS ISSUE# 16] Clarification of expression syntax
Issue 6802: DDS ISSUE# 17] Clarify consequence of changing partitions
Issue 6803: Behavior on creation failure
Issue 6804: DDS ISSUE# 19] Initial value of entity status changes
Issue 6805: DDS ISSUE# 20] Narrow the applicability of assert liveliness
Issue 6806: DDS ISSUE# 21] Helper operations
Issue 6807: Ref-134 Additional_w_timestamp_operations
Issue 6808: DDS ISSUE# 22] Details in the code generation
Issue 6809: ISSUE# 23] Make Listener inheritance explicit in figures 2-9 and 2-10
Issue 6810: DDS ISSUE# 24] Clarification of status flag
Issue 6811: DDS ISSUE# 25] Addition of read and take to ReadCondition
Issue 6812: DDS ISSUE# 26] Definition of DCPSKey
Issue 6813: DDS ISSUE# 27] Additional situations resulting in inconsistent QoS
Issue 6814: [DDS ISSUE# 28] Desirability to define "information model" in a file
Issue 6815: DDS ISSUE# 29] Disposing a multi-topic
Issue 6816: DDS ISSUE# 30] Setting of default qos on factories
Issue 6817: DDS ISSUE# 31] Topic QoS refactor
Issue 6818: DDS ISSUE# 32] Create dependencies on type
Issue 6819: DDS ISSUE# 33] Initialization of resources needed
Issue 6820: DDS ISSUE# 34] Initial data when DataWriter appears
Issue 6821: Inconsistency on what operations may return NOT_ENABLED
Issue 6822: DDS ISSUE# 36] QoS clarifications
Issue 6823: Ref-210 Clarification_of_responsibility_of_RxO_qos
Issue 6824: Ref-212 Qos_Coupling_TimeBasedFilter_deadline
Issue 6825: Ref-104 Coupling_bwn_TIME_BASED_FILTER_and_RELIABILITY
Issue 6826: Ref-156 Clarify_TIME_BASED_FILTER
Issue 6827: Ref-106 Desc_of_Inconsistent_topic_status::total_count_change
Issue 6828: Ref-108 Ownership_interaction_with_deadline
Issue 6829: Ref-109 Destination_order_should_be_request_offered
Issue 6830: Ref-111 Default_values_for_qos
Issue 6831: Ref-144 Wrong_description_of_compatible_DURABILITY
Issue 6832: Ref-165 Make_USER_DATA_changeable
Issue 6833: Ref-144 User_data_on_topic
Issue 6834: Ref-142 Confusing_description_of_manual_by_participant
Issue 6835: Ref-162 Separate_transient_into_two_kinds
Issue 6836: DDS ISSUE# 37] SAMPLE_LOST_STATUS on DataReader
Issue 6837: DDS ISSUE# 38] Allow application to install a clock
Issue 6838: DDS ISSUE# 39] Combine module names
Issue 6839: DDS ISSUE# 40] Expression syntax is missing enumeration
Issue 6840: DDS ISSUE# 41] Inconsistent use of instance in datawriter api
Issue 6841: DDS ISSUE# 42] Clarify how counts in the status accumulate
Issue 6842: DDS ISSUE# 43] Bad references
Issue 6843: Ref-139 Bad_reference_to filter_expression
Issue 6844: DDS ISSUE# 44] Errors in figures
Issue 6845: DDS ISSUE# 45] Is OMG IDL PSM more correct than CORBA PSM?
Issue 6846: DDS ISSUE# 46] Use of RETCODE_NOT_IMPLEMENTED
Issue 6848: Rename DataType interface to TypeSupport
Issue 6849: DDS ISSUE# 49] Behavior_of_register_type
Issue 6853: DDS ISSUE# 52] Provide for zero copy access to data
Issue 6854: DDS ISSUE# 53] Refactor lifecycle state
Issue 6855: Ref-85 Garbage_collection_of_disposed_instances
Issue 6856: Ref-112 Value_of_data_for_DISPOSED_state
Issue 6857: Ref-113 Meta_sample_accounting_towards_resource_limits
Issue 6858: DDS ISSUE# 54] Refactor or extend API used to access samples
Issue 6859: Ref-231 Provide_a_way_to_limit_count_returned_samples
Issue 6861: DDS ISSUE# 55] Rename DataType interface to TypeSupport
Issue 6862: DDS ISSUE# 56] Missing fields in builtin topics
Issue 6863: Ref-224 Built_in_topics_not_in_PSM
Issue 6864: DDS ISSUE# 57] Clarify creation of waitset and conditions
Issue 6867: ref-1032: User-provided oid
Issue 7022: ObjectHome index and name
Issue 7023: ObjectRoot::is_modified (clarification)
Issue 7024: New structure for DLRLOid
Issue 7025: Naming of the private members
Issue 7026: clean_modified (in ObjectRoot, Relations...)
Issue 7057: New definition for ObjectFilter
Issue 7058: Mapping DCPS-DLRL
Issue 7059: clone + deref
Issue 7060: Several instead one listener
Issue 7061: delete clone
Issue 7062: New definition for ObjectListener
Issue 7064: Ref-170 Missing_description_of_OWNERSHIP_STRENGH
Issue 7066: ref-171 Rename_Topic_USER_DATA_to_TOPIC_DATA
Issue 7067: New definition for Selections
Issue 7100: Missing operations on DomainParticipantFactory and need for helper values
Issue 7134: ref-1054: Bad which_added operations in IDL
Issue 7136: ref-1053 Missing is_composition
Issue 7169: Changing the IDL module

Issue 6685: DDS editorial issues (data-distribution-ftf)

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

[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

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.

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"

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)

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

Several readers wondered if the described metamodel should be implemented, while it is only given for description purpose
Proposal [THALES]
Add the following clarification sentence (at the end of the first paragraph of the section page 3.4):
" This metamodel is given for explanation purpose. This specification does not require that it is implemented as such."

In the class "Relation", the attribute "rel_needs_class" should be named "full_oid_required" (according to the text description)
In the class "Class" In the class "Relation", the attribute "id_needs_class" should be named "full_oid_required" (according to the text description)
Proposal [THALES]
Correct the figure

On that page, "Class", "Attribute" and "Relation" (line 2) and "Class" (first line before section 3.1.4.4.3) should be in bold+italics  as the other words that are identifiers
Proposal [THALES]
Correct the words

Issue [THALES]
In the textual description, the method "on_begin_updates" is named "start_updates" 
In the textual description, the method "on_end_updates" is named "end_updates"
Proposal [THALES]
Correct the textual description to align on the table.

Issue [THALES]
in the whole DLRL section, Annex C is badly named Annex A
Proposal [THALES]
Change all the "cf. annex A", with "cf. annex C"

Resolution: 
Change all the "cf. annex A", with "cf. annex C", everywhere in the whole DLRL section.

Issue [THALES]
in the final editing process, the IDL for the example has been truncated (cut by 2)
Proposal [THALES]
restore it as it was in version V67

Issue [THALES]
In the final editing process, 
the XML for the example has been truncated (cut by 2)
the chosen font makes it difficult to read (why not use Courier New which is a fixed-sized font as for the code example)
there should be a void line between the first sentence that introduces the XML description and the description itself
Proposal [THALES]
restore the contents as it was in version V67
introduce a void line to keep it separated from the introduction

Issue [THALES]
The style applied to the introduction to figure 3.9 is not correct
The figure itself is badly placed on the page
Proposal [THALES]
Correct the footprint

Issue [THALES]
In the final editing process, 
the minimum XML model tags for the example have been truncated (cut by 2)
the removal of the title makes less clear the purpose of the description
Proposal [THALES]
restore the contents as it was in version V67
change the last sentence of the introduction " In this case, the XML file would be as follows" with
"In case no deviation is wanted from the default mapping, the XML description can be restricted to the following minimum:"

Issue [THALES]
attribute "parameter" is stated as of type "string[}" instead "string []"
Proposal [THALES]
correct the table

Issue [THALES]
page 3-10: In figure 3-2 the class attribute min_topic should be main_topic
Proposal [THALES]
correct the figure

Issue [THALES]
page 3-62: Just after the XML listing: manual edition should be manual editing
Proposal [THALES]
correct the sentence

page 3-65: 4th line from below: t3->z(3000.0); t3 should be t2
Proposal [THALES]
correct the example

Issue [THALES]
1st bullet: section 3.1.4.4.2 (Mono Attribute) Class::topic should be Class::main_topic 
Proposal [THALES]
correct the wording

Issue [THALES]
In section 3.1.6.3.6 (ObjectListener) the method names used in the bulleted descriptions do not correspond to the names used in the Table
page 3-38: section 3.1.6.4.2 (Object Creation) first bullet: two times on_object_created is mentioned according to figure 3-4 this should be on_new_object.
Proposal [THALES]
correct the table (the bullets are in accordance with the IDL)
correct the figure (on_object_created is the name of the operation in other places, including IDL)

Issue [THALES]
in section 3.6.1.3.11 the clone method is named clone_object in the text explanation.
Proposal [THALES]
correct the text (everywhere else, the method is named clone)

Issue# 2010 Additional_communication_paradigms Issue [Boeing SOSCOE] ? In addition to the Data-Distribution model, our applications also need two basic communication models; Point2Point and GroupCommunications. ? The API’s and PIM defined in DDS would fit well with those communication models as well. That is, the concept of typed DataReaders and DataWriters that are configured by means of QoS and interact with the user-level application by means of listeners and conditions are all applicable to Point2Point and GroupCommunications. ? It would therefore be useful to introduce extensions such that the application can use these additional communication models in a way that fits naturally with the data-distribution PIM. ? In Boeing SOSCOE’s applications Point2Point communications: • Represent 1-to-1 bi-directional communication channels similar to UNIX “pipes” that can be configured by means of QoS • Are “connection-oriented” in the sense that each endpoint must explicitly establish the “connection” and is made aware if the “connection” is broken • Allow the application to read-write typed data to the other end-point. Each “writer” in one side of the connection communicates with the corresponding “reader” at the other end. In general each writer must be matched by a reader at the opposite end. Otherwise it is a configuration error. • Allow prioritization among the data written by different writers by means of QoS • Allow both synchronous and asynchronous writes. • Support the concept of application-level acknowledgements or “transactional” messaging by which the writing application can receive notification that the reading application has received the message and has positively acted on it. • Support the classic “client-connect versus server-listen/accept” pattern such that the “server” side can establish multiple dedicated point-to-point connections to each “client” that requests a connection. • Filters are not generally expected to be required for Point2Point communications. However, in order to keep the same API they should be allowed. The middleware should automatically give positive acknowledgement of reliable or transactional data that has been filtered out. • It is an error for a data-writer to write a Topic that does not have a corresponding data-reader. The writer() call should return a special error code indication there is no matching DataReader. In Boeing SOSCOE’s applications GroupCommunications : • Provide the capability for a group of peer applications to organize themselves into a “group”, such that each member of the group is aware of the presence of all other members and can send messages directed to either one specific peer, all the peers in the group, or a subset of the members of the group. • Provide some means to control group membership. • Each member of the group is identified by some “ID” such that other members can refer to it and direct messages to it. • Provide a serialized view of membership and delivery of messages such that: • The writer knows the membership when it sends each message and anybody that does not belong to that membership will not get the message. • All members of the group have the same view of the membership for each message delivered to them. • Do not need to provide total order or even agreed order. • Act as a “live” group in that messages are only delivered to the members that are present when the message is sent. In other words, it does not store messages on behalf of future members of the group • It is OK to write a DataWriter that does not have a corresponding DataReader on some of the other Group members. The data is considered acknowledged for RELIABLE but not for the purpose of TRANSACTIONAL (ref issue# 2060). Proposal [Boeing SOSCOE] ? Consider introducing a more primitive concept for a group of endpoints, from which the following classes derive: Publisher, Subscriber, EndpointConnector, and GroupConnector. ? This base class could be called “Connector” but does not really mean a “connection” in the “TCP” sense, rather the “connectivity” into the middleware services. ? All these “Connectors” act as factories for DataReader and DataWriter entities (which represent the Endpoints). ? The type of the DataReader and DataWriter created from each kind of “Connector” is the same (even though they will act differently). This is because the DataReader and DataWriter are typed facades to write a specific data-type and it is not desirable to have to create (by means of implied IDL) different types for each kind of connector. ? The EndpointConnectors and GroupConnectors are informed of the connections/disconnections by means of Listeners with an “onConnect” and “onDisconnect” operations. ? For Point2Point communication the factory of DataReader and DataWriter entities would be the EndpointConnector • To match the two EndpointConnector objects that should be “hooked up” the application could use either a Topic, or a more general matching of “Attibute-value” pairs, or a combination of the above. • To aid in the establishment of many point2point connectors using the client-connect, server-listen/accept pattern the EndpointConnector could use an auxiliary “ServerConnector” and corresponding listeners that would inform it of the fact that clients are attempting a connection. ? For Group communications the factory of DataReader and DataWriter entities would be the GroupConnector • The same generic mechanism used by the EndpointConnector should be used to identify the group the GroupConnector entities are joining, that is either a Topic, or a more general matching of “Attibute-value” pairs, or a combination of the above. Comments[RTI] ? To avoid confusion it might be a good idea to propose a name other than “connector” for the base class and also avoid the use of the terms “client” and “server” which are often associated with the pattern of communications used by CORBA and RMI. ? Point2Point communications would never use KEEP_LAST QoS. They will use KEEP_ALL. They will also always have DURABILITY TRANSIENT. In a sense messages are sent to the other end “immediately” and held only as long as is necessary to ensure the QoS (e.g. RELIABLE or TRANSACTIONAL) afterwards they are removed from the middleware. 

Point-to-point communications and Group communications are not included in the Data-Distribution specification and their inclusion would be beyond the scope of the FTF. Other OMG specifications address Group communications and one-way messaging as extensions to the CORBA remote-method-invocation model. However, it appears that what is requested here is a "messaging" API, so this issue may be better addressed by means of an RFP.

Attributes_on_a_topic_description Issue [Boeing SOSCOE] ? Some use-cases need more control on association of DataReader and DataWriters beyond the control offered by means of the Topic ? For example, SOSCOE may need to add a layer on top of the DDS API to offer additional customized services to the applications that sit on top. These services may include the propagation of identity-certificates, security, dynamic selection of the “best” DataWriter to use for a given Topic, etc. ? These mechanisms would like to benefit from the propagation of Topics and QoS that DDS offers and extend that mechanism with additional information that can then be used by the SOSCOE layer to provide these additional services. ? However the matching that DDS offers is performed only on the topic name. It would be useful to have a more extensible mechanism to allow matching on other application-defined attributes. ? These attributes are an expansion of the topic_name that appears in the TopicDescription. In addition to the string (topic_name) we could have a set of attribute-name/value pairs that could then be used to match the writers with readers. In a sense the topic_name would be a singular, mandatory attribute used for matching but they could be others. ? These attributes are not mutable. ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types. ? For example, the Topic “weather data” would describe a general topic but there may be an attribute that describes the region (e.g. “North America”) and the subscriber can specify they want weather-data but only over “North America” Proposal [Boeing SOSCOE] ? One approach would be to add a set of “name-value” attributes to the TopicDescription. Matching would be done not only on the topic-name but also on the remaining attributes. In a sense, the topic name is just one of the attributes that must be matched between the Topic that is published and that which is subscribed.

Issue# 2030 Extension_to_the_partition_qos Issue [Boeing SOSCOE] ? The DDS specification provides the means for an application to configure the “connectivity” of DataReaders and DataWriters by setting the PARTITION QoS on the corresponding Publisher and Subscriber. ? Partitions therefore provide means for publishers and subscribers to restrict the associations that can be established between the readers and writers they contain. ? This facility is useful, but the fact that the matching is done by strict string matching of the partition-name strings can be limiting. ? It would be desirable to have something more extensible like “name-value” pairs and some more flexible expression language (e.g. a filter expression) to indicate the matching, beyond pure string matching. ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types (ref Issue#2035). ? A potential use case is to use name-value pairs to identify the source of the information or a distribution restriction. Things like AREA_NAME, SENSOR_GROUP, etc. each with its value. ? This is the analogous to the attribute-value pairs on the topic except they apply to the Publisher/Subscriber or EndpointConnectors. Proposal [Boeing] ? Addition of a set of name-value pairs to the Publisher and Subscriber (in fact to all Connectors) which can then be used to determine whether the endpoints contained in the connectors should communicate ? The attributes in the Connector can be used to locate providers of interest or somehow the “best” provider where “best” can be specific to each peer Connector. ? The query language described in Appendix A would not be sufficient for SOSCOE’s needs due to the need for function expressions and, at some future time, the ability to support well-known structured types (ref Issue#2035). 

Issue# 2060 Transactional_reliability Issue [Boeing SOSCOE] ? For the case of Point2Point and Group communications there is a need to have “application-level” reliability where the sender can find out if a message was (1) delivered to the receiving application(s) and (2) whether it was successfully processed by the receiving application(s). ? SOSCOE uses the name “TRANSACTIONAL” to refer to this kind of application-level message-processed confirmation. ? This would only make sense for HISTORY QoS KEEP_ALL. TRANSACTIONAL and KEEP_LAST would be considered inconsistent QoS settings. Proposal [Boeing SOSCOE] ? Add the kind TRANSACTIONAL to Reliability QoS policy ? Add DataReader::set_transaction_status (or some operation to allow receiving application to accept or reject a transactional message) ? Add listener operations to the DataWriter to get notified of the transactional status. Potentially add also a method to the DataWriter to query the transactional status. ? Add a DataWriter::rewrite(WriteMessageID). This only applies to EndpointConnectors or GroupConnectors that have transactional QoS set. This handles the case where the message was transmitted to the receiving end and put on the reader queue successfully but the reading application does not set the transactional status indicating that the message was processed. The rewrite() is a convenience so that the writing application does not have to re-create the message but is being treated by the infrastructure as a message that needs to be sent again because the reader has presumably erased it from its queues. 

This issue affects the Point-to-Point communications model introduced in issue 6729.

Issue# 2070 Writer_notification_of_delivery_failure Issue [Boeing SOSCOE] ? This requirement applies to Point2Point and Group communications, not to Pub/Sub. ? In the case where the QoS is set to RELIABLE or TRANSACTIONAL there is a need for the application to be notified of delivery failures and also find out the delivery-status of individual messages. ? The application needs to get delivery confirmation with the granularity of a single message. ? Notification of delivery can be either synchronous (wait for delivery) or asynchronous (notification via listener). Proposal [Boeing SOSCOE] ? Add DataWriterListener::on_sent_data_lost and DataWriterListener::on_sent_data_received listener methods to notify sender asynchronously of reliable message send status ? Add UserListenerData for use in transactional and reliable processing. This data is specified on each write() and given back to the user through the DataWriterListener::on_sent_data_lost and DataWriterListener::on_sent_data_received methods to help the user determine what should be done with the data. ? Provide a way to get the ID of each message written (WriteMessageID). This can be used by the user to learn more about the message that was lost or received and is used by the system to track transactional and reliable messages that might have to be present. This id is passed to the on_sent_data_lost and on_sent_data_received listener methods and could become invalid at the end of those methods (the system must have some consistent way of determining when to clean up). Comment [RTI] ? In order for the application to find out the status of an individual message it needs to have some way to identify each message. Currently the DDS specification does not provide said mechanism. ? There are several ways to extend DDS to provide message identification functionality. • One way would be to change the return value of DataWriter::write() to return some kind of messageID or handle that can be used to refer to that message. Or alternatively return the messageId as an out parameter. However, this approach may complicate the application which now would need to perhaps track these IDs. • Another would be to add an operation to DataWriter to get the messageId of the last message written. This would have the advantage that it does not require a change of the API, just an extension. However, this would be potentially less efficient and also not safe if multiple application threads are using the same DataWriter to send information. • Another approach is that the MessageId would only be available by means of the callback. • With regards to the UserListenerData, it appears it needs to be either a parameter to the write call, or else something that could be set using a separate call. The first would clearly be more efficient but increases the complexity of the write API. 

This issue depends on the additional communication models introduced in issue 6729

Issue# 2085 Navigation_of_connectivity_information Issue [Boeing SOSCOE] ? There is no way to use the DDS API to find some of the information that is available internally to the service. ? For example there is no way to determine & enumerate the remote readers that are “associated” with a local writer, or the remote writers associated with a local reader. ? The DDS specification does provide a way to “name/identify” the remote entities. This is the DCPSKey that appears as part of the fields of the built-in-topics which are the ones used to access discovery information on remote entities. Proposal [Boeing SOSCOE] ? Add iterators to the DataReader and DataWriter entities that allow enumerating the remote entities (identified by DCPSKey) associated with it. ? Add helper operations that allow determining the QoS associated with remote entities (identified by DCPSKey) 

Issue# 2090 Additional_qos_DATA_PRIORITY Issue [Boeing SOSCOE] ? Need for additional DATA_PRIORITY Qos on the DataWriter. This Policy defines a priority that is associated with the data contained in a message and would serve two purposes: • 1) It would provide a prioritization mechanism for the transport, and • 2) It would determine how the receiver queues things in the data reader ? For the SOSCOE application this policy would have to support at least 5 values each with descending priority: (Flash_Override, Flash, Immediate, Priority, Routine) ? Ideally there would be a way to propagate and map this to whatever underlying transport is being used to send the messages. ? In its effect on the queuing on the receiving side it acts as a DESTINATION_ORDER QoS. In effect, the order would be BY_PRIORITY. ? Note that it would be possible to have DESTINATION_ORDER BY_PRIORITY and HISTORY KEEP_LAST. In this case, the reader may throw away the higher priority data if another message arrives. This is OK. If this is not the desired behavior, then the application should specify KEEP_ALL (which is expected to be the normal use in practice). Proposal [Boeing SOSCOE] ? Add a DATA_PRIORITY Qos. 

Issue# 2100 Additional_qos_LIFESPAN Issue [Boeing SOSCOE] ? The LIFESPAN Qos Policy that prevents “stale” data from being delivered to receiving applications. ? The LIFESPAN defines a time period for which the data should live. If a message cannot be delivered before the specified time period, the message is dropped. This value is expressed in time units, it should not be confused with a network-level Time-To-Live (TTL), that could be set on network connections which is expressed in number of hops. ? LIFESPAN is specified as a “span” that is a time interval measured from the time the data is written. ? LIFESPAN should be mutable. ? LIFESPAN needs to be specified only in the writer side. ? Note that this QoS assumes that the sender and receiving applications have their clocks sufficiently synchronized. ? The filtering could be done on the sending side, on the receiving side, or both. It would be an implementation decision that would only affect performance but would otherwise not be observable by the application. ? If data is dropped because the LIFESPAN value expires, Reliable and Transactional QoS would still require the writer to be notified of the failure to deliver. Proposal [Boeing SOSCOE] ? Introduce the LIFESPAN Qos. 

Issue# 2140 Make_USER_DATA_an_array_and_mutable Issue [Boeing SOSCOE] ? There are several potentially independent uses for USER_DATA. It would be useful to have it as a set of name-value pairs or other extensible construct. That way layers such as SOSCOE could add its own USER_DATA and not conflict with the uses that the application above SOSCOE may make of the data. ? SOSCOE has created a provider property class that allows applications to have attributes with typed values; it becomes a triplet (name, type, value). Currently the “type” only supports simple types, but the intent is to extend it to well-known structured types (ref Issue#2035). The extension of the USER_DATA can be used to implement these properties. Proposal [Boeing SOSCOE] ? Make USER_DATA a set of name-value pairs and make it mutable. ? Alternatively keep the USER_DATA as it is for the simple cases and add something more flexible for the more complex cases.

The resolution of issue 6832 made the USER_DATA mutable.
It appears that the application already has the means of using a structured type inside the USER_DATA and hence get the requested behavior

Issue [THALES]
There in no means to retrieve a previously created Cache
Proposal [THALES]
Add on the CacheFactory::create_cache an extra parameter that is the name of the Cache
Add the CacheFactory::find_cache method
IDL
Cache create_cache (in CacheUsage usage, 
		in DCPS::DomainParticipant domain,
		in string name)
	raises (DCPSError, AlreadyExisting);
Cache find_cache (in string name)
	raises (NotFound);
concerns the PIM (figure, table and text and the PSM)

Issue [THALES]
Currently the valuetypes ObjectRoot, RefRelation, ListRelation, IntMapRelation and StrMapRelation use a supported interface in order to gather their respective attributes and operations. This can be simplified in defining directly the attributes and operations on the valuetypes
Proposal [THALES] 
define the corresponding attributes and operations directly in the valuetypes
concern only the PSM

Issue [THALES]
The attribute ObjectHome is named 'owner' and would be better named 'home'
The attribute CacheAccess is named 'cache' and would be better named 'access'
Proposal [THALES]
change as indicated
concerns the PIM (figure, table and text) and the PSM

Issue [THALES]
The ObjectRoot::clone operation takes as parameter an ObjectScope (only the object, the object + all its components, the object + all its components + all its related objects). In the latter case, this may result in cloning a lot of objects
Proposal [THALES]
Add an extra parameter to limit the depth of cloning for related objects, with a dedicated value for unlimited
Precise that if some related objects are not cloned (depending on the ObjectScope and RelatedObjectsDepth) , traversing the related relation should raise the NotFound exception (cf. ref-1026)
IDL
typedef  short RelatedObjectDepth;
const RelatedObjectDepth UNLIMITED_RELATED_OBJECT_DEPTH -1;
OidRef clone (in CacheAccess access,
		in ObjectScope scope,
		in RelatedObjectDepth depth)
	raises (ReadOnlyMode);
concerns the PIM (table and text and the PSM)

Issue [THALES]
The operations of the CacheAccess are not sufficiently clearly described, that lead to some confusions
Proposal [THALES]
Enhance section 3.1.6.1.2.2 (Cache Management), in introducing better the underlying concepts; in particular, clarify the dynamics with respects to enable/disable updates
Introduce that the specification is designed to allow lazy instantiation 
Describe more deeply the CacheAccess operations (section 3.1.6.3.2); in particular state how they will behave with respects to enable/disable updates
Enhance the description of typical uses of CacheAccess (section 3.1.6.5)

Issue [THALES]
The operation is badly named delete_cache in the PSM (instead of delete_access)
The parameter is badly stated as CacheUsage (instead of CacheAccess) in the PIM (in the table for Cache operations)
Proposal [THALES]
Correct the PSM and the PIM table

Issue [THALES]
What does deref when no corresponding object exist in the related CacheAccess or if the object has been deleted?
Proposal [THALES]
In that case, the deref operation should raise an exception (NotFound in the first case - cf. issue ref-1023, and Deleted in the second?)

Issue [THALES] 
Rather name those types StringSeq and LongSeq as in DCPS
Proposal [THALES]
Actually 2 different naming rules conflict:
list of xxx -> xxxSeq
all user-created types starting with a capital letter
Give the precedence to the second!

Issue [THALES]
This operation is not described in the text of section 3.1.6.3.5
Proposal [THALES]
add the description in the text (at the end of the operation list)
"retrieve the name of the DCPS Topic that contains the value for one attribute (get_topic_name)"

Issue [THALES]
Getting all the names of all the topics that are used to store objects of a given class may be rather cumbersome
Proposal [THALES]
add an operation to get all in a single call
IDL
StringSeq get_all_topic_names()
Concerns the PIM (figure, table and text) and the PSM

Issue [THALES]
Rather than returning a sequence of objects as the list of instances and let the application iterate in it, it seems better to let the infrastructure iterate by providing operations that would
filter the objects
apply a modifier on the objects
Proposal [THALES]
Introduce a new class FooExtent that would embed a sequence of Foo and provide those operations.
Make the find_objects returning a FooExtent to allow to filter on a filtered result (like was allowed with the initial ObjectFilter::filter)
Suppres the filter operation in an ObjectFilter (that is now redundant)
Replace the list of instances in FooHome and FooSelection, by an instance of this class
IDL
local interface FooFilter : DLRL::ObjectFilter
{
	boolean check_object (in Foo an_object);
}
local interface FooModifier: DLRL::ObjectModifier
{
	void modify_objects (in Foo an_object);
}
local interface FooExtend: DLRL::OjectExtent
{
	readonly attribute FooSeq objects;
	FooExtent  find_objects (in FooFilter filter);
	void modify_objects (in FooFilter filter,
		in FooModifier modifier);
}
local interface FooHome
{
	readonly attribute FooExtent extent;	// instead of FooSeq
}
local interface FooSelection
{
	readonly attribute FooExtent members;// instead of FooSeq
}
concerns the PIM (figure, list of interfaces, interface sections - table and text) and the PSM

Issue [THALES]
This object is referred (in attributes or operations as refs (ex - refs, deref); therefore the name of the class ObjectLink is confusing
Proposal [THALES]
Rename this construct as OidRef
Concerns the PIM (figure, list of entities, entities sections - tables and texts) and the PSM

***Ref-04 Initialization_of_DomainParticipantFactory


The specification does not define how the application gets the
DomainParticipantFactory if each implementation uses a different
mechanism it would make applications non portable.


***PROPOSAL***


Modify section 2.1.2.2.2 adding the static operation "get_instance" to
DomainParticipantFactory. This operation will return the factory which
is a singleton. If the method is called multiple times the same
factory is returned

***Ref-05 IDL_case_sensitive


In the PSM, the IDL uses as formal parameter names the same string as
the name of the type only distinguished by the case.  This appears to
treat IDL as a case sensitive language which is not, and would result
in problems in languages such as ADA that are not case sensitive.


This problem appears in several paces where "topic" appears as the
formal parameter name of an argument of type "Topic". For instance the
operations TopicListener::on_inconsistent_topic,
DomainParticipant::delete_topic, Subscriber::create_datareader
Similarly "listener" appears as the formal parameter name of an
argument of a type derived from Listener. For instance the operations
DomainParticipant::create_publisher,
DomainParticipant::create_subscriber, DomainParticipant::create_topic,
DomainParticipantFactory::create_participant
Publisher::create_datawriter, Subscriber::create_datareader


***PROPOSAL*** To avoid confusion use "a_topic" for the formal
parameter name of any parameter of type "Topic", or any specialization
of Topic.


Similarly use "a_listener" for the formal parameter name of any
parameter of type "Listener", or any specialization of Topic.

Naming_of_attribute_getter_operations


DataWriter class table, and DataReader class table operations
get_liveliness_lost_status, get_offered_deadline_missed_status and
get_offered_incompatible_qos_status.


In the IDL file, these getter methods are specified as readonly
attributes with the same names, but without the preceeding
"get_". This leads to getter methods with different names in different
languages (In C++ the"get_" part will disappear, in Java only the "_"
will disappear).


These IDL-to-language mappings would invalidate the PIM.  To avoid
this kinds of issues we should avoid using attributes in either the
PIM or the PSM. The use of explicit operations will make the PIM more
easily mappede to different PSMs.


***PROPOSAL***


Replace the readonly attributes in the PIM or PSM with explicit
get_xxx operations. Replace any read-write attributes attributes in
the PIM or PSM with explicit get_xxx and set_xxx operations.

Section 2.1.2.5.9. The set_query_arguments method is of type void, and
can therefore not return an Error status.


***PROPOSAL***


Subsumed by proposal to Ref-50. Explicit operation to set the
attribute will return ReturnCode_t

Delete dependencies and semantics


***Ref-19 Delete_dependencies


Delete operations on Entities are only allowed if all other Entities
which have dependencies with it have been deleted first (for example,
a Topic may not be deleted before all other Entities depending on this
Topic have been deleted first)


The specification does not explain what happens if an application
tries to delete an entity that has dependent or contained entities.


This applies to Sections: 2.1.2.2.1.2, 2.1.2.2.1.4, 2.1.2.2.1.6,
2.1.2.2.1.8, 2.1.2.2.1.10, and 2.1.2.2.2.2.


Given that Topic object can be obtained by means of the
DomainParticipant::create_topic operation as well as the
DomainParticipant::lookup_topic operation there is an ambiguity
regarding the deletion of Topic objects prior to deleting the
DomainParticipant. Should the application call delete just on the ones
it obtained by means of "create_topic" or also on the ones obtained by
means of "lookup_topic"


***PROPOSAL***


State that if said "delete" operations are called while there are
dependent or contained entities the operation will fail and return
PRECONDITION_NOT_MET.


Fix by adding get_datareader() operation to the ReadCondition. This
operation should take no arguments and return a DataReader


Also state that the application should also delete the Topic obtained
by means of lookup_topic as this is needed to remote the local
resources devoted to it.

The specification does not state what happens if the application tries
to use an entity after it has been deleted by means of the
corresponding "delete" operation on the factory. This is specially
relevant in languages such as Java (or C++ when using the "var" types)
that automatically maintain reference counts. Is the deletion delayed
until the last reference is release?


***PROPOSAL***


Modify section 2.1.1.1 and ad the return code
ALREADY_DELETED. Similarly add the "const ReturnCode_t RETCODE_
ALREADY_DELETED = 9" to the IDL in section 2.2.3


State that it is an error for the application to use an entity after
it has been deleted. Also state that, in general the result is
unspecified and may depend on the implementation or the PSM. Also
state that in the cases where the implementation can detect this, the
operation that uses the deleted entity should return RETCODE_
ALREADY_DELETED (e.g. calling DataWriter::write on a data writer that
has been deleted).

Section 2.1.2.2.1.11 indicates that topics can be made globally
available. So "creation" can have a global effect.


It is not clear therefore whether deletion of a Topic also has a
global effect.


***PROPOSAL***


Add to that paragraph in section 2.1.2.2.1.11. "In any case
delete_topic deletes only the local proxy.

The specification does not state what happens if the applcation
attempts to create multiple times a Topic with the same name


***PROPOSAL***


In section 2.1.2.2.1.5 state that calling create_topic muiltiple times
behaves as doing a lookup first with no timeout and if a Topic is
found then it compares the data-type & the qos specified as parameters
with those of the existing Topic.


State that if the comparison fails, than the operation return
PRECONDITION_FAILED.


State that if the lookup and comparison succeed then the reference
count to the Topic should be incremented such that the application
must call delete_topic as many times as it called create_topic and
directly lookup_topic for the local proxy to be deleted.

The specification describes that an entity cannot be deleted if it has
contained entities. That is: Cannot delete Publisher if local
datawriters. Cannot delete Pubscriber if local datareaders. Cannot
delete DomainParticipant if any Topics, Publishers, Subscribers.


However manually deleting all contained entities is cumbersome in the
case in which the application is trying to do so as is the case when
shutting down.


***PROPOSAL***


Add the operation "ReturnCode_t delete_contained_entities()" to
DomainParticipant, Publisher, and Subscriber.


This operation will return all contained entities and leave the system
in a state that allows the application to delete the container.  This
affects sections 2.1.2.2.1, 2.1.2.4.1, 2.1.2.5.2, and 2.2.3 (IDL)

The specification does not mention what to do when an entity is passed
to a delete method in a factory object, for which that factory object
is not owner? (For example a DataWriter is passed to the
delete_datawriter method of Publisher A, while it was created in
Publisher B.)


This applies to Sections: 2.1.2.2.1.2, 2.1.2.2.1.4, 2.1.2.2.1.6,
2.1.2.2.1.8, 2.1.2.2.1.10, 2.1.2.4.1.6, 2.1.2.5.2.6, and 2.1.2.5.3.7


***PROPOSAL***


State that if said "delete" operations are called passing the wrong
factory, the operation shall fail and return PRECONDITION_NOT_MET.

Ref-27 Single_waitset_attachement_to_condition


Section 2.1.2.1. Why can only one "WaitSet" be associated with a
"Condition". This contradicts figure 2-7 and figure 2-9.


This seems too limiting. When this is combined with the fact that each
entity has a single status condition we end up in a situation where
one thread can wait on an entity changing states.


***PROPOSAL***


Correct section 2.1.2.1 and figure 2-5 to indicate that it is possible
to attach the same condition to multiple waitsets

Ref-35 Entity_specialization_set_get_qos


The specification shows this operation as being abstract on the
base-class (Entity) and says that it will be overridden by each
specialization (Section 2.1.2.1.1.2). This is consistent with the PSM.


However, the get_qos/set_qos operations are not mentioned in the
tables and text that that describe the DomainParticipant (section
2.1.2.2.1.


Also for the specialized Entity classes, the operations are not
mantioned on the class table but do appear in the text that describes
the table. This applies to Topic (section 2.1.2.3.2), Publisher
(section 2.1.2.4.1), DataWriter (section 2.1.2.4.2), Subscriber
(section 2.1.2.5.2), and DataReader (section 2.1.2.5.3).


***PROPOSAL***


In order to avoid ambiguity, the get_qos/set_qos operation should
appear explicitly in all the aforementioned sections.

The specification shows these operations as being abstract on the
base-class (Entity) and says that it will be overridden by each
specialization (Section 2.1.2.1.1.3). This is consistent with the PSM.


However, the get_listener/set_ listener operations are not mentioned
in the tables and text that that describe the DomainParticipant
(section 2.1.2.2.1.


Also for the specialized Entity classes, the operations are not
mantioned on the class table but do appear in the text that describes
the table. This applies to DomainParticipant (section 2.1.2.2.1),
Topic (section 2.1.2.3.2), Publisher (section 2.1.2.4.1), DataWriter
(section 2.1.2.4.2), Subscriber (section 2.1.2.5.2), and DataReader
(section 2.1.2.5.3.


***PROPOSAL***


In order to avoid ambiguity, the get_listener/set_listener operation
should appear explicitly in all the aforementioned sections.

***Ref-38 DomainParticipant_domainId


Section 2.1.2.2.1. DomainParticipant class table. The attribute
domainId is not mentioned although mentioned in the IDL PSM.


***PROPOSAL***


Correct PIM.

Section 2.1.2.2.1. DomainParticipant class table defines an operation
called delete_contentfilteredtopic. This operation is named
inconsistently in the IDL PSM (section 2.2.3) where it appears as
delete_contentfiltered in the IDL PSM.


***PROPOSAL***


Change the name of the operation in the IDL to
delete_contentfilteredtopic.

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.

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

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

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

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.

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.

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

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

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.

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.

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.

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.

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.

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

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

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

Attribute/accessor for SampleRejectedStatus missing from 2.1.2.5.3


***PROPOSAL***


Add the get_xxx accesor to the DataReader class

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

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

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.

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.

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.

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.

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.

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.

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

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 = { 0x7ffffff, 0xffffffff }

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 = { -1, 0 }

Sometimes it is necessary to represent a zero duration as well as an
invalid time.


A zero duration is needed for example to provide the value of a
minimum_separation when a TIME_BASED_FILTER is not desired.


An invalid time is needed when samples are returned that do not
represent actual data.


The representation of a DURATION_ZERO clearly is a Time_t with values
{0, 0}. However it is desirable that the name of this constant is
standardized across implementations.


***PROPOSAL***


Add the following constant to the IDL:


Timestamp t DURATION_ZERO = { 0, 0 }

Ref-13 Semantics_of_register_unregister_instance


The semantics of the register_instance and unregister_instance methods
are not entirely clear. From section 2.1.2.5.1 it seems that both
methods have, apart from their local memory management purpose on the
Publisher side, also a purpose with respect to determining the
LIVELINESS of a DataWriter on the Subscriber side. This means that
these methods will probably result in network communication as well


***PROPOSAL***


Clarify the semantics by adding the following paragraphs as needed to
sections 2.1.2.5 and to 2.1.3:


The need for registering/unregistering instances stems from two use
cases: (1) Ownership resolution on redundant systems, and (2)
Detection of loss in topological connectivity and the consequent
difference in the semantics of unregister and dispose (3).


(1) Ownership resolution on redundant systems


It is expected that users will use DDS to set up redundant systems
where multiple DataWriters are "capable" of writing the same
instance. The data-writers are either configured such that both are
writing the instance "constantly" or else they use some mechanism to
monitor each other and only write when they detect that the primary
"writer" is no longer writing.


Either of the above two cases uses the OWNERSHIP policy "Exclusive"
and arbitrate themselves by means of the OWNERSHIP_STRENGTH. The
desired behavior is that when the "primary" writer stops writing, the
application should start to receive data from the secondary subscriber


This approach requires some mechanism to detect that the "writer" is
no longer "writing" the data as it should. There are several reasons
why this may be happening and all must be detected (but not
necessarily distinguished):


The writing process is no longer running (e.g. the whole application
has crashed)


Connectivity to the writing application has been lost (e.g. network
got disconnected)


Application logic that was writing the data is faulty and has stopped
doing so.


Arbitrating from a writer to one of a higher strength is simple and
the decision can be taken autonomously by the reader. Switching
ownership from a higher strength writer to one of a lower strength
requires that the "reader" application can make a determination that
the "writer" application is "no longer writing the instance".


(1.1) Case where the data is periodically updated


This determination is reasonably simple when the data is being written
periodically at some rate. The writer simply states its offered
deadline (maximum interval between updates) and the reader monitors
that the writer indeed updates the instance at least once per
deadline_period. If the deadline is missed, the reader considers the
writer "not alive" and gives ownership to the highest-strength writer
that is alive


(1.2) Case where data is not periodically updated


The case where the writer is not writing data periodically is also a
very important use-case. Since the data is not being updated at any
fixed period, the "deadline" mechanism cannot be used to determine
ownership. The liveliness neatly solves this situation. Ownership is
maintained while the writer is "alive" and for the writer to be alive
it must be fulfill its "LIVELINESS" contract. The different means to
renew liveliness (automatic, manual) combined by the implied renewal
each time data is written handle the three conditions above (a), (b),
or (c) ( note that to handle (c) Liveliness must be
MANUAL_BY_TOPIC). Now the writer can retain ownership by periodically
writing data or else calling assert_liveliness() if it has no data to
write. Alternatively if only protection against (a) or (b) is desired,
it is sufficient that some task on the writer process periodically
writes data or calls assert_liveliness() on the participant.


However, this scenario requires that the reader knows what instances
are being "written" by the writer. That is the only way that the
reader can maintain ownership of specific instances from the fact that
the writer is still "alive". Hence the need for the writer to
"register" and "unregister" instances. Note that while "registration"
can be done lazily the first time the writer writes the instance,
"unregistration" in general cannot. Unless we are willing to say that
once a writer writes an instance it will forever write the instance
until the writer is deleted. Similar reasoning will lead to the fact
that unregistration will also require a message to be sent to the
readers


(2) Detection of loss in topological connectivity


There are applications that are designed in such way that their
correct operation requires some minimal topological connectivity, that
is, the writer needs to have a minimum number or readers or
alternatively the reader must have a minimum number of writers.


A common scenario is that the application does not start doing is
logic until it knows that some specific writers have the minimum
configured readers (e.g the alarm monitor is up).


A more common scenario is that the application logic will wait until
some writers appear that can provide some needed source of information
(e.g. the raw sensor data that must be processed).


Furthermore once the application is running it is a requirement that
this minimal connectivity (from the source of the data) is monitored
and the application informed if it is ever lost. For the case where
data is being written periodically, the DEADLINE QoS and the
on_deadline_missed() listener provides the notification. The case
where data is not periodically updated requires the use of the
LIVELINESS in combination with register/unregister instance to detect
whether the "connectivity" has been lost, and the notification is
provided by means of the "NO_WRITERS" lifecycle state.


In term of the required mechanisms the scenario is very similar to the
case of maintaining ownership. In both cases the reader needs to know
whether a writer is still "managing the current value of an instance"
even though it is not continually writing it and this knowledge
requires the writer to keep its liveliness plus some means to know
which instances the writer is currently "managing" (i.e. the
registered instances).


Note that the need to notify the reader that a particular instance has
no writers does not imply that the mechanism is the use of a
"NO_WRITES" lifecycle. We could just as well use a listener. The
listener mechanism has the problem that there is no way to know which
instances are the ones that have no writers. But this is also a
problem for the "on_deadline_missed" listener so we think it would be
a good idea to refractor these two mechanisms to that they are similar
in nature and both provide the means to determine which instances have
the problem.


(3) Difference between unregister and dispose


Dispose is different than unregister. The "dispose" indicates that the
data-instance no longer exists (e.g. a track that has disappeared, a
simulation entity that has been destroyed, a record entry that has
been deleted, etc.) whereas the "unregister" indicates that the writer
is no longer taking responsibility for updating the value of the
instance.


Deleting a data-writer is equivalent to unregistering all the
instances it was writing, but is not the same as "disposing" all the
instances.


For a topic with EXCLUSIVE ownership if the current owner of an
instance disposes it, the readers an instance will see the lifecycle
as being "DELETED" and not see the values being written by the weaker
writer (even after the stronger one has disposed the instance). This
is because the owner of the instance is saying that the instance no
longer exists (e.g. the master of the database is saying that a record
has been deleted) and thus the readers should see it as such.


For a topic with EXCLUSIVE ownership if the current owner of an
instance unregisters it than it will relinquish ownership and thus the
readers will see the value updated by another writer (which will then
become the owner). This is because the owner said that it no longer
will be providing values for the instance and thus any other writer
can take ownership and provide those values

Ref-14 Relationship_of_IDL_and_expression_syntax


The fieldnames and topicnames used in SQL expressions need to be
language-independent. This means that they have to be derived from the
IDL-definition. The SQL description in Annex A/B does not define the
relationship between the FIELDNAME and the IDL definition.


Example, assume the following IDL definition:


module mymodule { struct mystruct { long record; }; };


The SQL statement could become "SELECT record AS value FROM
mymodule.mystruct ...".


The field "record" would be translated into "IDL_record" by an ADA
preprocessor. The SQL-statement should still use "record" to be
language independent. This is a generic situation that occurs for each
language when the name of the field matches a reserved keyword.


***PROPOSAL***


Improve specification "Annex A/B" stating that the syntax of the SQL
statement will match the names used in IDL not necessarily those of
the language mapping.

Ref-17 PartitionQos_behavior_on_change


The specification does not make it clear whether changing the
PARTITION QoS on a Publisher or Subscriber affects the existing
DataReader or DataWriter establishing some "associations" that did not
exist before, or breaking associations that existed.


Furthermore the specification does not describe whether the
INCOMPATIBLE_QOS listeners/ status will be triggered


Given that partitions are intended to be used to separate logically
separate 'communication words' so that you can isolate things it would
seem that changing partitions should affect existing DataReader and
writers and not trigger the INCOMPATIBLE_QOS.


***PROPOSAL***


Modify section 2.1.3.9 to clarify that (1) changing the PARTITION QoS
on a Publisher or Subscriber does affect the existing DataReader or
DataWriter entities. It may establish new "associations" that did not
exist before, or break existing associations.


Also explain in section 2.1.3.9 that not matching the PARTITION QoS
does not trigger the INCOMPATIBLE_QOS listener nor change the
associated status.

Ref-21 Error_status_on_create_calls


The specification does not explain the return value of the factory
"create" calls if the operation fails, for example due to inconsistent
QoS.


***PROPOSAL***


Add text that explains that in case of failure the return value is NIL
(as defined on each PSM).


This affects 2.1.2.2.2.1, 2.1.2.2.1.1, 2.1.2.2.1.5, 2.1.2.2.1.7,
2.1.2.2.1.9, 2.1.2.4.1.5, 2.1.2.5.2.5

Ref-26 Initial_value_of_entity_status


The specification does not define the initial value of the status of
an entity after initializations/enabling


***PROPOSAL***


Specify in section 2.1.2.1.1.6 that when the entity is created the
return of get_status_changes is an empty mask indicating that no
status have changed

Ref-29 Entity_operation_assert_livelines


Class Entity has a function assert_liveliness, which is inherited by
all derived classes. However, this function is relevant in combination
with the LIVELINESS QoS policy only, and has only defined behavior on
DomainParticipant and DataWriter


***PROPOSAL*** Remove assert_liveliness from Entity and introduce it
in DataWriter and Participant

Ref-32 Quering_waitset_for_attached_conditions


The WaitSet class has methods for attaching and detaching conditions
to it, but no method for querying which conditions are attached.


***PROPOSAL***


In section 2.1.2.1.6 add a get_conditions method that returns a
ReturnCode_t and has a collection of conditions as an out
paramater. In section 2.2.3 (IDL) add the corresponding operation.

It seems that the samples that indicate the 'disposing' of an instance
need to also be sorted with respect to other samples and the sorting
should follow DESTINATION_ORDER policy


However if DESTINATION_ORDER is BY_SOURCE_TIMESTAMP and the
application is explicitly passing the timestamp to write_w_timestamp
there is no way to also specify the time when an instance is disposed


The same applies to unregister. It may be necessary to order it with
respect to other events


***PROPOSAL***


Add a dispose_w_timestamp operation to DataWriter.


Add an unregister_w_timestamp operation to DataWriter

Ref-47 Details_on_type_specific_code_generation


Section 2.1.2.3.7 says "It is required that each implementation of the
Service provides an automatic means to generate this type-specific
class from a description of the type (using IDL for example in the
CORBA mapping)."


The details of this generation for the CORBA mapping should be
mentioned in the CORBA PSM (Section 2.2).


***PROPOSAL***


Add to section 2.1.2.3.7 the clarification that IDL should be used for
the language and perhaps also a figure similar to Figure 3-3 in
section 3.1.4.5 (in the DLRL) showing the process with potential
vendor-specific file for keys or QoS

Ref-51Forward_mention_PublisherListener_inheritance and Ref-61
Forward_reference_SubscriberListener_baseclass


In 2.1.2.4 the PublisherListener interface extends the
DataWriterListener, this is not mentioned until 2.1.4.3 after
PulisherListener has been described


The same applies to 2.1.2.5 with SubscriberListener and
dataReaderListener


***PROPOSAL***


Modify figures 2-9 and 2-10 to show this relationships. Or at least
mention them in section 2.1.2.4.3 and 2.1.2.5.6

Ref-64 Association_of_status_and_statuschangedflag


Why does every status have an associated object "StatusChangedFlag"
instead of a boolean attribute "changed"?


Figure 2-14 (2.1.4.2) is at least misleading and should be clarified
regarding this point. It suggests a 1 to n relation with a
"StatusChangedFlag" class.


Even though the diagram was only meant as conceptual explanation, not
for providing an implementation architecture it would be desirable to
improve specification in this respect.


***PROPOSAL***


Add text to 2.1.4.2 to explain that this figure is conceptual and
simply represents that the Entity knows which specific statuses have
changed, it does not imply a particular implementation in terms of
Boolean flags.

Ref-60 Adding_read_take_to_ReadCondition


Why not have a read and take operation on readcondition instread of
read_w_condition and take_w_condition?


In the current situation the middleware must perform consistency
checking and handle error conditions.


Moving the read and take to the readCondition will require generation
of typed interfaces but this is merely a wrapper around the current
situation avoiding the error prone design.


For example, if a Waitset has many query conditions. Then the
application would need to find the reader that matches it. Adding a
get_reader in the querycondition would not give a strongly-typed
reader.


The simplest solution is to have a read in the querycondition.


***PROPOSAL***


create the ReadCondition and QueryReadCondition as implied IDL


We will move create_readcondition to the FooDataReader


Add a read to the Read and QueryConditions


Remove the read_w_condition from the DataReader and FooDataReader

Ref-68 Definition_of_DCPSKey


Section 2.1.5. This section introduces a type DCPSKey, this type is
not specified anywhere.


This key however is only used for the built-in types so it would be
better if, to avoid confusion, is named BuiltinTopicKey_t


***PROPOSAL***


Rename DCPSKey to be BuiltinTopicKey_t


Define it in the IDL PSM the same way IntanceHandle_t is defined so
that each vendor can define it as needed.

Ref-73 Depth_must_be_less_or_equal_ max_samples_per_instance


Clarify that depth <= max_samples_per_instance otherwise its an
inconsistent QoS


***PROPOSAL***


State this requirement in 2.1.3.12 and 2.1.2.13

Ref-77 Offering_the_possibility_to_define_topics_in_a_file _


It would be desirable to have an "information model" where the QoS of
the topics is specified in some file.


This information model would also contain the QoS for the Topic.


***PROPOSAL***


No action as this seems beyond what the FTF could solve.

Ref-83 Multitopic_refactor _


The specification does not say when a MultiTopic is disposed


***PROPOSAL***


State in section 2.1.2.3.4 that MultiTopic will dispose as soon as one
of the underlying Topic that are its components is disposed

Ref-?? Setting_default_qos_on_factories


The specification provides a way to create Entities with QoS by
explicitly providing the QoS when the entity is created.


In some cases it would be desirable to provide a pattern such that
many entities can be easily created with the same QoS without the
application explicitly. Thst way the management of the Qos can be
"centralized" in few modules in the application logic


***PROPOSAL***


Add the following operations:


DomainParticipant::set_default_publisher_qos(),
DomainParticipant::get_default_publisher_qos(),
DomainParticipant::set_default_subscriber_qos(),
DomainParticipant::get_default_subscriber_qos(),
Publisher::set_default_datawriter_qos(),
Publisher::get_default_datawriter_qos(),
Subscriber::set_default_datawriter_qos(),
Subscriber::get_default_datawriter_qos().


This allows the application to set a default QoS for the entities that
the factory will create, and then explicitly use that QoS to create
the entities.


Furthermore specify that if the set_default_xxx_qos operations are not
called then the get_default_xxx_qos will return the defaults specified
in section 2.1.3

Ref-86 Topic_qos_refactor and Ref-150
Tracking_of_topic_properties_by_reader_writer


The reason for the DDS specification to add QoS to the Topic was to
allow annotating the information-model with Topic QoS settings. That
way it is possible for the individual applications and their designers
to be relieved from many details and configure the writers/readers
from this information model.


However the definition of the Topic QoS does not match this.


Section 2.1.2.4.3.2 describes a model where if the QoS is 'not set' on
a dataWriter or a DataReader, then the one of the Topic is used
instead. Furthermore it says that in this situation the QoS of the
Entity will "track" that of the Topic.


These statements are not consistent with the PIM or PSM as there is no
way provided to 'not set' a QoS. All the API's force complete setting
of the QoS.


Furthermore the 'tracking' behavior would be very hard to implement
and it would also be very confusing for an user that has a QoS of an
entity magically change when the QoS of the topic changes. Lastly it
would also be hard to handle the case where as a result of the
'tracking' the QoS of an entity becomes incompatible with that of
other entities already associated with it.


Given all this it would be desirable to make the use of Topic QoS
consistent with the API's and also simpler to implement and understand


***PROPOSAL***


Modify section 2.1.2.4.3.2.


Remove all references to behaviors regarding what happens if some QoS
is "not set" rather say that QoS is always explicitly set although it
can be set from defaults in the factories.


Also remove the sentence regarding how the entity QoS can "track" the
Topic qos.


Explain that the pattern to create an entity with "default" QoS is to
get the default qos from the factory, and also get it from the Topic,
and then modify the desired policies before creating the entity.


To assist this common pattern we recommend adding the following
utility operations:


Publisher::initialize_from_topic_qos(inout DataReaderQos qos, in Topic
a_topic, in long mask)


Subscriber::initialize_from_topic_qos(inout DataWriterQos qos, in
Topic a_topic, in long mask)


Specify that all QoS on Topic is immutable.

Ref-89 State_dependency_register_type_create_datareader_writer


The specification does not say clearly whether a TopicDescription can
be created if the associated type has not been registered and what
happens if the user tries to do that.


***PROPOSAL***


State explicitly that the operations that create specializations of
TopicDescription, that is, create_topic and create_multitopic and
lookup_topic, Will return PRECONDITION_NOT_MET if type not locally
registered

] Initialization of resources needed to implement
DURABILITY TRANSIENT or PERSISTENT


***Ref-91 Configuration_of_the_transient_and_persistent_service


The DDS specification does not provide a clear model of the behavior
of the service when the DURABILITY QoS is set to TRANSIENT or
PERSISTENT


Moreover for the application needs to be able to specify the QoS
parameters and resources that the implementation is allowed to use
when implementing this service.


***PROPOSAL***


Add the following explanation to section 2.1.3.2:


For the purpose of implementing the the DURABILITY QoS settings of
TRANSIENT, PERSISTENT the service behaves "as if" it had a "built-in
DataReader and DataWriter" for each Topic that is configured to have
said DURABILITY kind. In other words, it is "as if" somewhere in the
system (possibly on a remote node) there was a "built-in durability"
DataReader that subscribed to that Topic and a "built-in durability"
DataWriter that published that Topic as needed for the new subscribers
that join the system.


For each Topic, the built-in "persistence service"
datareader/datawriter has its QoS configured from the Topic QoS for
that Topic as described in Issue Topic_qos_refactor (Issue #86). In
otherwords, it is as-if the service first did a
"Participant::lookup_topic" for that Topic, and then used the QoS on
the Topic to configure the built-in entities.


As a consequence of this model, the transient or persistence serviced
can be configured by means of setting the proper QoS on the Topic.


For a given Topic, the usual request/offered semantics apply to the
matching between any DataWriter in the system that writes the Topic
and the built-in transient/persistent DataReader for that
Topic. Similarly for the builtin transient/persistent DataWriter for
the Topic and any DataReader for the Topic. As a consequence, a
DataWriter that has an incompatible QoS with respect to what the Topic
specified for the built-in transient/persistent DataReader will not
send its data to the transient/persistent service, and a DataReader
that has incompatible QoS with respect to the specified in the Topic
for the transient/persistent DataWriter will not get data from it.


Incompatibilities between local DataReader/DataWriter entities and the
corresponding builtin transient/persistent entities cause the
"incompatible qos" listener to be invoked as they would with any other
entity.

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.

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

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"

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".

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.

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.

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

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"

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."

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.

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)

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"

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.

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.

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

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

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

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.

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'

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

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

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

***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

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

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

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

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.

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

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.

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

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 = {NEW, NOT_NEW}


liveness_lifecycle = { ALIVE , DISPOSE_EXPLICIT, DISPOSED_NO_WRITERS }


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.

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.

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

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

Resolution: 
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.
The resolution of this issue was already included in the resolution of issue  6856.
Disposition:	Duplicate/merged (issue 6856)

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 {


struct SampleInfo *info;


struct Foo *data;


};


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.

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.

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

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]

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

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.

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.

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

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."

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 {
	unsigned long creator_id;
	unsigned long local_id;
	};
	[instead typedef long DLRLOid]

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]

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.

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 {
	UNDEFINED_MEMBERSHIP,
	ALREADY_MEMBER,
	NOT_MEMBER
	};

local interface ObjectFilter  {
	/*IMPLIED*
	boolean check_object (
		in Object 			an_object,
		in MembershipState		membership_state);
		[addition of this parameter]
	*IMPLIED*/
	};
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 {
	...
	readonly attribute boolean concerns_contained;
		[addition]
	...
	};
local interface SelectionListener {
	...
	[the following method is no more commented out for it will not be redefined in the derived implied IDL]
	void on_object_out (
		in ObjectReference the_ref);
			[instead in ObjectRoot the_object]
	};
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."

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

Proposal [THALES]
Reconsider this point and introduce the possibility to  manage a key to/from oid explicit mapping
Adapt the XML description of the mapping to support the case when the keys cannot transport the oid.
introduce a new element "keyDescription" which will describe the nature of the key with respect to the oid and that will allow for a variable number of key fields
In any case, this will have no impact on the operations that can be performed on the DLRL objects
Concrete changes
in section 3.1.4.2 Mapping Rules
Insert a new paragraph in third position with the following content:
"Generally speaking, there exist some flexibility in designing the DCPS model that can be used to map a DLRL model. Nevertheless, there exist cases when the underlying DCPS model exists with no provision for storing the object references and no possibility to be modified. In that case however, the DCPS topics contain fields that allow to uniquely identify instances (the keys). With some restrictions concerning inheritance, these models can also be mapped back into DLRL models. Section 3.1.4.5 is specifically dedicated to that issue."
Modify the last paragraph as follows:
"The mapping rules when some flexibility is allowed in DCPS model are as follows:"
After section 3.1.4.4.5 MultiRelation, insert a new section: "3.1.4.5	Mapping when DCPS Model is Fixed"
First paragraph with the following text:
"In some occasions, it is desirable to map an existing DCPS model to DLRL. It is even desirable to mix in the same system participants that act at DCPS level with other that acts at DLRL level. DLRL, by not imposing the same object model to be shared among all participants is even designed to allow this last feature."
Second paragraph with the following content:
"In this case, it is possible to use the topic keys to identify the objects, but not to store directly the object references. Therefore the DLRL implementation must be indicated the topic fields that are used to store the keys so it can  manage under the scenes the association keys to/from oid and perform the needed indirection."
Third paragraph with the following content:
"Because the object model remains local, this is generally feasible but cannot support inheritance between the applicative classes (beyond the primary inheritance between an applicative class and ObjectRoot).  However an exiting DCPS model will not, by construction, support inheritance between its 'classes'. Therefore such a mapping is supported."
The next section is now numbered " 3.1.4.6 How is this Mapping Indicated?" [instead formerly 3.1.4.5]
In section "3.2.3.3.1 Models Tags DTD
Replace the full description of mainTopic with the following:
"<!ELEMENT mainTopic (keyDescription)>"
"<!ATTLIST mainTopic name CDATA  #REQUIRED>"
Replace the full description of extensionTopic with the following:
"<!ELEMENT extensionTopic (keyDescription)>"
"<!ATTLIST extensionTopic name CDATA  #REQUIRED>"
Replace the element description of monoRelation by the following
"<!ELEMENT monoRelation (placeTopic?,keyDescription)>"
Replace the element description of  multiRelation by the following
"<!ELEMENT multiRelation (multiPlaceTopic,keyDescription)>"
Discard the now useless full description of  valueKey, by removing the following lines:
"<!ELEMENT valueKey […] >"
"<!ATTLIST valueKey […]>"
Replace the full description of placeTopic with the following
"<!ELEMENT placeTopic (keyDescription)>"
"<!ATTLIST placeTopic name CDATA  #REQUIRED>"
Replace the full description of multiPlaceTopic with the following
"<!ELEMENT multiPlaceTopic (keyDescription)>"
"<!ATTLIST multiPlaceTopic name CDATA  #REQUIRED
		      indexField CDATA  #REQUIRED>"
Add the full description of keyDescription, by inserting the following
"<!ELEMENT keyDescription (keyField*)>"
"<!ATTLIST keyDescription content (FullOid | SimpleOid | NoOid) #REQUIRED>"
Add the full description of keyField, by inserting the following
"<!ELEMENT keyField (#PCDATA)>"
In section 3.2.2.3.2.6 ClassMapping
Second bullet, correct "sub-tab" into "sub-tag"
In section 3.2.2.3.2.7 MainTopic
Change the second paragraph to the following
" It comprises one attribute name that gives the name of the Topic and:"
insert then one bullet with the following content:
"a mandatory sub-tag keyDescription."
Discard the rest of the section until the example.
Replace the example to the following:
"<mainTopic name="TRACK-TOPIC">
		<keyDescription 
		...
		</keyDescription>
	</mainTopic>"
Insert then a section "3.2.2.3.2.8 KeyDescription"
First paragraph, with text:
"This tag describes the key to be associated to several elements (mainTopic, extensionTopic, placeTopic and multiPlaceTopic)."
Second paragraph, with text:
"It comprises an attribute that describes the content of the keyDescription, that can be:"
Followed by 3 bullets
First bullet:
"FullOid, in that case, the key description should contain as first keyField the name of the Topic field used to store the class name and as second keyField the name of the Topic field  used to store the OID itself;"
Second  bullet:
"SimpleOid, in that case the key description should only contain one keyField to contain the OID itself;"
Third bullet:
"NoOid, in that case the case description should contain as many keyField that are needed to identify uniquely one row in the related Topic and it is the responsibility of the DLRL implementation to manage the association between those fields and the DLRLOid as perceived by the application developer."
Last paragraph as follows:
"It contains also as many elements keyField as needed."
Followed by an example, as follows:
"Example:
<keyDescription content="SimpleOid">
	<keyField>OID</keyField>
</keyDescription>"
Then sections 3.2.2.3.2.x, starting from 3.2.2.3.2.9 ExtensionTable have their number increased by 1
In section 3.2.2.3.2.10 MonoAttribute
Change the example to the following
"<monoAttribute name="y">
       <placeTopic name="Y_TOPIC">
	       <keyDescription content="SimpleOID">
			<keyField>OID</keyField>
	       </keyDescription>
	</placeTopic>
      <valueField>Y</valueField>
</monoAttribute>"
In section 3.2.2.3.2.11 MultiAttribute
Change the example to the following:
"<multiAttribute name="comments">
         <multiPlaceTopic name="COMMENTS-TOPIC"
                 <keyDescription content="FullOID">
		         <keyField>CLASS</keyField>
		         <keyField>OID</keyField>
		</keyDescription>
	     </multiPlaceTopic>
     	     <valueField>COMMENT</valueField>
</multiAttribute>"
In section 3.2.2.3.2.12 MonoRelation
Last bullet, change the name of the sub-tag ffrom "valueKey" to "keyDescription"
Change the example to the following:
"<multiAttribute name="comments">
	<multiPlaceTopic name="COMMENTS-TOPIC"
		<keyDescription content="FullOID">
			<keyField>CLASS</keyField>
			<keyField>OID</keyField>
		</keyDescription>
	</multiPlaceTopic>
     	<valueField>COMMENT</valueField>
</multiAttribute>"
In section 3.2.2.3.2.13 MultiRelation
Change the example to the following:
"<multiRelation name="tracks">
	<multiPlaceTopic name="RADARTRACKS-TOPIC"
	         <keyDescription content="SimpleOID">
		     <keyField>RADAR-OID</keyField> 
	         </keyDescription>
	<\multiPlaceTopic>
	<keyDescription content="FullSimpleOID">
	         <keyField>TRACK-CLASS</keyField> 
	         <keyField>TRACK-OID</keyField>
	</keyDescription>
</multiRelation>
In section 3.2.3.3 XML Model Tags
Change the full example to the following
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Dlrl SYSTEM "dlrl.dtd">
<Dlrl name="example">
   <templateDef name="StringStrMap" pattern="StrMap" itemType="string"/>
   <templateDef name="RadarRef" pattern="Ref" itemType="Radar"/>
   <templateDef name="TrackList" pattern="List" itemType="Track"/>
   <classMapping name="Track">
      <mainTopic name="TRACK-TOPIC">
         <keyDescription content="FullOid">
            <keyField>CLASS</keyField>
            <keyField>OID</keyField>
         </keyDescription>
      </mainTopic>
      <monoAttribute name="x">
         <valueField>X</valueField>
      </monoAttribute>
      <monoAttribute name="y">
         <placeTopic name="Y_TOPIC">
            <keyDescription content="FullOid">
               <keyField>CLASS</keyField>
               <keyField>OID</keyField>
            </keyDescription>
         </placeTopic>
         <valueField>Y</valueField>
      </monoAttribute>
      <multiAttribute name="comments">
         <multiPlaceTopic name="COMMENTS-TOPIC" indexField="INDEX">
            <keyDescription content="FullOid">
               <keyField>CLASS</keyField>
               <keyField>OID</keyField>
            </keyDescription>
         </multiPlaceTopic>
         <valueField>COMMENT</valueField>
      </multiAttribute>
      <monoRelation name="a_radar">
         <keyDescription content="SimpleOid">
            <keyField>RADAR_OID</keyField>
         </keyDescription>
      </monoRelation>
      <local name="w"/>
   </classMapping>
   <classMapping name="Track3D">
      <mainTopic name="TRACK-TOPIC">
         <keyDescription content="FullOid">
            <keyField>CLASS</keyField>
            <keyField>OID</keyField>
         </keyDescription>
      </mainTopic>
      <extensionTopic name="TRACK3D-TOPIC">
         <keyDescription content="FullOid">
            <keyField>CLASS</keyField>
            <keyField>OID</keyField>
         </keyDescription>
      </extensionTopic>
      <monoAttribute name="z">
         <valueField>Z</valueField>
      </monoAttribute>
   </classMapping>
   <classMapping name="Radar">
      <mainTopic name="RADAR-TOPIC">
         <keyDescription content="SimpleOid">
            <keyField>OID</keyField>
         </keyDescription>
      </mainTopic>
      <multiRelation name="tracks">
         <multiPlaceTopic name="RADARTRACKS-TOPIC" indexField="INDEX">
            <keyDescription content="SimpleOid">
               <keyField>RADAR-OID</keyField>
            </keyDescription>
         </multiPlaceTopic>
         <keyDescription content="FullOid">
            <keyField>TRACK-CLASS</keyField>
            <keyField>TRACK-OID</keyField>
         </keyDescription>
      </multiRelation>
   </classMapping>
   <associationDef>
      <relation class="Track" attribute="a_radar"/>
      <relation class="Radar" attribute="tracks"/>
   </associationDef>
</Dlrl>

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)"

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."

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);"

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.

Proposal [THALES]
Change slightly the definition of listeners, by passing the ObjectReference instead the object itself, adding the old value when appropriate and introducing a forth method (on_contained_object_modified).
Specify at each ObjectListener attachment whether it should apply only on the object or on the object + its contained ones and discard the attribute notification_scope on ObjectHome
Concrete changes
IDL
typedef RelationName string;
enum RelationKind {
	REF_RELATION,
	LIST_RELMATION,
	INT_MAP_RELATION,
	STR_MAP_RELATION};
valuetype RelationDescription {
	public RelationKind	kind;
	public RelationName	name;	
	};
valuetype ListRelationDescription ; RelationDescription {
	public long index;
	};
valuetype IntMapRelation : RelationDescription {
	public long key;
	};
valuetype StrMapRelation : RelationDescription {
	public string key;
	};
local interface ObjectListener {
	[methods are no more commented out]
	boolean on_object_created(
		in ObjectReference ref);
	boolean on_object_modified(
		in ObjectReference ref,
		in ObjectRoot old_value);
	boolean on_contained_object_modified(
		in ObjectReference ref,
		in RelationDescription relation_desc,
		in ObjectReference contained_ref,
		in ObjectRoot old_contained_value);
	boolean on_object_deleted(
		in ObjectReference ref);
local interface ObjectHome {
	...
	[discard the readonly attribute notification_scope]
	...
	[attach_listener is no more commented out]
	void attach_listener (
		in ObjectListener	listener,
		in boolean		concerns_contaied_object);
		[instead only the first parameter]
	...
in section 3.1.6.3.5 ObjectHome
in the table,
in the attribute list, discard the entry for the attribute notification_scope
in the operations list, add a new parameter to the attach_listener entry; attach_listener is now as follows:
attach_listener		void
	listener	ObjectListener
	concerns_contained_objects	boolean
in the following list starting with "the public attributes give":
discard the third bullet ("the scope to [...] has changed.")
in the following list starting with "it offers methods to":
append to the second bullet ("attach/detach [...] detach_listener);), the following sentence:
"when a listener is attached, a boolean parameter specifies, when set to TRUE, that the listener should listen also for the modifications of the contained objects (concerns_contained_objects);"
in section 3.1.6.3.6 Object Listener
in the table, change the list of operations to the following:
on_object_created		boolean
	ref	ObjectReference
on_objcet_modified		boolean
	ref	ObjectReference
	old_value	ObjectRoot
on_contained_object_modified		boolean
	ref	ObjectReference
	relation_desc	RelationDesc
	contained_ref	ObjectReference
	old_value	boolean
on_object_deleted		boolean
	ref	ObjectReference
in the following text, change the header of the list with the following:
"It is defined with four methods:" [instead of 3]
append at the end of first bullet:
"this operations is called with the ObjectReference of the newly created object (ref);"
append to the end of the second bullet:
"this operation is called with the ObjectReference of the newly deleted object (ref);"
append at the end of the third bullet:
" this operation is called with the ObjectReference of the modified object (ref) and its old value (old_value); the old value may be NULL;"
add a fourth bullet, with the following content:
"on_contained_object_modified which is called when the contents of a contained object has been modified; this operation is called with the ObjectReference of the container object (ref), the ObjectReference of the modified contained object (contained_ref), a description of the relation that links those two objects (relation_desc, including the name of the relation and if appropriate the index that corresponds to the contained object) and old value of the contained  object (old_contained_value); the old value may be NULL;

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 .

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.

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 {
	...
	readonly attribute boolean concerns_contained;
		[addition]
	...
	};
local interface SelectionListener {
	...
	[the following method is no more commented out for it will not be redefined in the derived implied IDL]
	void on_object_out (
		in ObjectReference the_ref);
			[instead in ObjectRoot the_object]
	};
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."

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

***PROPOSAL***


Concrete changes:
Section 2.1.2.2.2 DomainParticipantFactory Class
DomainParticipantFactory table :
Add operation set_default_participant_qos
Parameters:
qos_list : QosPolicy []
Return: ReturnCode_t
Add operation get_default_participant_qos
Parameters:
out qos_list : QosPolicy []
Return: void


Add subsections:


2.1.2.2.2.5 set_default_ participant_qos
This operation sets a default value of the DomainParticipant QoS policies which will be used for newly created DomainParticipant entities in the case where the QoS policies are not explicitly specified in the create_participant operation.
This operation will check that the resulting policies are self consistent, if they are not the operation will have no effect have no effect and return INCONSISTENT_POLICY.


2.1.2.2.2.6 get_default_participant_qos
This operation retrieves the default value of the DomainParticipant QoS, that is, the QoS policies which will be used for newly created DomainParticipant entities in the case where the QoS policies are not explicitly specified in the create_participant operation.
The values retrieved get_default_participant_qos will match the set of values specified on the last succesful call to set_default_participant_qos, or else, if the call was never made, the default values listed in the QoS table in Section 2.1.3 .


This operation will check that the resulting policies are self consistent, if they are not the operation will have no effect have no effect and return INCONSISTENT_POLICY.
Section 2.1.2.2.1.1 create_publisher
Add paragraph after the 2^nd paragraph “If the specified QoS policies are not compatible, the operation will fail…”
The special value PUBLISHER_QOS_DEFAULT can be used to indicate that the Publisher should be created with the default Publisher QoS set in the factory. The use of this value is equivalent to the application obtaining the default Publisher QoS by means of the operation get_default_publisher_qos (Section 2.1.2.2.1.21 ) and using the resulting QoS to create the Publisher.
Section 2.1.2.2.1.3 create_subscriber
Add paragraph after the 2^nd paragraph “If the specified QoS policies are not compatible, the operation will fail…”
The special value SUBSCRIBER_QOS_DEFAULT can be used to indicate that the Subscriber should be created with the default Subscriber QoS set in the factory. The use of this value is equivalent to the application obtaining the default Subscriber QoS by means of the operation get_default_subscriber_qos (Section 2.1.2.2.1.21 ) and using the resulting QoS to create the Subscriber.
Section 2.1.2.2.1.5 create_topic
Add paragraph after the 2^nd paragraph “If the specified QoS policies are not compatible, the operation will fail…”
The special value TOPIC_QOS_DEFAULT can be used to indicate that the Topic should be created with the default Topic QoS set in the factory. The use of this value is equivalent to the application obtaining the default Topic QoS by means of the operation get_default_topic_qos (Section 2.1.2.2.1.21 ) and using the resulting QoS to create the Topic.
Section 2.1.2.2.2.1 create_participant
Add paragraphs after the 1^st paragraph “This operation creates a new DomainParticipant object…”
If the specified QoS policies are not compatible, the operation will fail and no DomainParticipant will be created.
The special value PARTICIPANT_QOS_DEFAULT can be used to indicate that the DomainParticipant should be created with the default DomainParticipant QoS set in the factory. The use of this value is equivalent to the application obtaining the default DomainParticipant QoS by means of the operation get_default_participant_qos (Section 2.1.2.2.2.6 ) and using the resulting QoS to create the DomainParticipant.


Section 2.1.2.4.1.5 create_datawriter
Add paragraph after the bullets that are introduced with the heading “Note that a common application pattern to construct the QoS…”
The special value DATAWRITER_QOS_DEFAULT can be used to indicate that the DataWriter should be created with the default DataWriter QoS set in the factory. The use of this value is equivalent to the application obtaining the default DataWriter QoS by means of the operation get_default_datawriter_qos (Section 2.1.2.4.1.14 ) and using the resulting QoS to create the DataWriter.
The special value DATAWRITER_QOS_USE_TOPIC_QOS can be used to indicate that the DataWriter should be created with a combination of the default DataWriter QoS and the Topic QoS. The use of this value is equivalent to the application obtaining the default DataWriter QoS and the Topic QoS (by means of the operation Topic::get_qos) and then combining these two QoS using the operation copy_from_topic_qos whereby any policy that is set on the Topic QoS “overrides” the corresponding policy on the default QoS. The resulting QoS is then applied to the creation of the DataWriter.


Section 2.1.2.5.2.5 create_datareader
Add paragraph after the bullets that are introduced with the heading “Note that a common application pattern to construct the QoS…”
The special value DATAREADER_QOS_DEFAULT can be used to indicate that the DataReader should be created with the default DataReader QoS set in the factory. The use of this value is equivalent to the application obtaining the default DataReader QoS by means of the operation get_default_datareader_qos (Section 2.1.2.4.1.14 ) and using the resulting QoS to create the DataReader.
The special value DATAWRITER_QOS_USE_TOPIC_QOS can be used to indicate that the DataReader should be created with a combination of the default DataReader QoS and the Topic QoS. The use of this value is equivalent to the application obtaining the default DataReader QoS and the Topic QoS (by means of the operation Topic::get_qos) and then combining these two QoS using the operation copy_from_topic_qos whereby any policy that is set on the Topic QoS “overrides” the corresponding policy on the default QoS. The resulting QoS is then applied to the creation of the DataReader.


Section 2.1.2.2.2.3 get_instance
After the 1^st paragraph “This operation returns…” add the paragraph:
The pre-defined value TheParticipantFactory can also be used as an alias for the singleton factory returned by the operation get_instance.


Section 2.2.3 DCPS PSM : IDL
Interface DomainParticipantFactory add:
ReturnCode_t set_default_ participant_qos(in DomainParticipantQos qos);
void get_default_ participant qos(inout DomainParticipantQos qos);
DomainParticipant lookup_participant(in DomainId_t domainId);


Add the following lines to the IDL:
#define TheParticipantFactory
#define PARTICIPANT_QOS_DEFAULT
#define TOPIC_QOS_DEFAULT
#define PUBLISHER_QOS_DEFAULT
#define SUBSCRIBER_QOS_DEFAULT
#define DATAWRITER_QOS_DEFAULT
#define DATAREADER_QOS_DEFAULT
#define DATAWRITER_QOS_USE_TOPIC_QOS
#define DATAREADER_QOS_USE_TOPIC_QOS

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 ();]

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

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.

The FTF feels 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 the target 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.