Issues for Data Distribution Service Finalization Task Force

To comment on any of these issues, send email to data-distribution-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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 6732: Extension_to_the_query_language
Issue 6733: Attributes_on_the_data
Issue 6734: Filtered_out_lifecycle_state Issue
Issue 6735: Transactional_reliability Issue
Issue 6736: Writer_notification_of_delivery_failure Issue
Issue 6737: Detection_of_dynamic_qos_failure Issue
Issue 6738: Navigation_of_connectivity_information Issue
Issue 6739: Additional_qos_DATA_PRIORITY Issue
Issue 6740: Additional_qos_LIFESPAN Issue
Issue 6741: Additional_qos_THROUGHPUT Issue
Issue 6742: Key_separate_from_data 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 6847: DDS ISSUE# 47] Allow application to not specify a timstamp
Issue 6848: Rename DataType interface to TypeSupport
Issue 6849: DDS ISSUE# 49] Behavior_of_register_type
Issue 6850: DDS ISSUE# 50] Multiple observers sharing a datareader
Issue 6851: DDS ISSUE# 51] Avoid use of dynamic memory for manipulating QoS
Issue 6852: Ref-167 Malloc_required_for_get_default_qos
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 6860: Ref-232 Allow_reader_to_access_partition_of_writer
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 7065: ref-1053 Missing is_composition
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)

Click here for this issue's archive.
Source: Real-Time Innovations (Dr. Gerardo Pardo-Castellote, Ph.D., gerardo@rti.com pardo@rti.com)
Nature: Uncategorized Issue
Severity:
Summary: 
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

Resolution: see below
Revised Text: Resolution1: Correct table in Section 2.1.5 as described Revised Text1: Move text "DCPSPublication (entry created when a DataWriter is created in association with its Publisher)" to the cell above where it currently is. Move the text "DCPSSubscription (entry created when a DataReader is created in association with its Subscriber)" to the cell above wher it currently is. Straddle together the Cell containing "DCPSParticipant (entry created when a DomainParticipant object is created)" with the one directly below Straddle together the cell containing "DCPSTopic (entry created when a Topic object is created)" with the 2 cells that follow directly below Straddle together the cell containing "DCPSPublication (entry created when a DataWriter is created in association with its Publisher)" with the 3 cells that follow directly below Straddle together the cell containing "DCPSSubscription (entry created when a DataReader is created in association with its Subscriber)" with the 3 cells that follow directly below Resulting table in section 2.1.5 is: Topic name Field Name Type Meaning DCPSParticipant(entry created when a DomainParticipant object is created) key BuiltinTopicKey_t DCPS key to distinguish entries user_data UserDataQosPolicy Policy of the corresponding DomainParticipant DCPSTopic(entry created when a Topic object is created) key BuiltinTopicKey_t DCPS key to distinguish entries name string Name of the Topic type_name string Name of the type attached to the Topic DCPSPublication(entry created when a DataWriter is created in association with its Publisher) key BuiltinTopicKey_t DCPS key to distinguish entries topic_name string Name of the related Topic partition PartitionQosPolicy Policy of the Publisher to which the DataWriter belongs user_data UserDataQosPolicy Policy of the corresponding DataWriter DCPSSubscription(entry created when a DataReader is created in association with its Subscriber) key BuiltinTopicKey_t DCPS key to distinguish entries topic_name string Name of the related Topic partition PartitionQosPolicy Policy of the Subscriber to which the DataReader belongs user_data UserDataQosPolicy Policy of the corresponding DataReader Disposition1: Resolved Summary2: Ref-103 Typo_on_section_2.1.2.5.2.8 3rd paragraph says: "In the aforementioned case, the operation begin_access must be called prior to calling any of the sample-accessing operations, namely: get_datareaders on the Subscriber and read, take, read_w_condition, take_w_condition on any DataWriter." Should say "on the DataReader" instead of "on the DataWriter". Resolution2: Replace say "on the DataWriter" instead of "on the DataReader" Revised Text2: In the aforementioned case, the operation begin_access must be called prior to calling any of the sample-accessing operations, namely: get_datareaders on the Subscriber and read, take, read_w_condition, take_w_condition on any DataReader. Disposition2: Resolved Summary3: Ref-105 Typo_on_section_2.1.3.11 Section 2.1.3.11 says "The setting BY_SOURCE_TIMESTAMP indicates that, assuming the STRENGTH policy allows it, a timestamp placed at the source should be used. " Should say "...assuming the OWNERSHIP policy allows it…" Resolution3: Replace as stated above Revised Text3: The setting BY_SOURCE_TIMESTAMP indicates that, assuming the OWNERSHIP policy allows it, a timestamp placed at the source should be used. Disposition3: Resolved Summary4: 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 Resolution4: Replace "publication" with DataWriter in 2.1.2.2.1.15 Revised Text4: The DataWriter to ignore is identified by the handle argument. Disposition4: Resolved Summary5: 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" Resolution5: Replace as stated above Revised Text5: Outside steady state the HISTORY and RESOURCE_LIMITS policies will determine how samples become part of the history and whether samples can be discarded from it Disposition5: Resolved Summary6: Ref-145 Bad_reference_to_DCPSEntity Section 2.1.3 Figure 2-15 Says DCPSEntity instead of Entity in one of the lines Resolution6: Replace as stated above Revised Text6: Disposition6: Resolved Summary7: 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. Resolution7: Make the "r" italic. Revised Text7: The built-in DataReader objects can be retrieved by using the operation get_datareader, with the Subscriber and the topic name as parameters. Disposition7: Resolved Summary8: 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....."" Resolution8: The first and last typos are true typos. The second (2.1.2.5.2.8: 3rd paragraph, 3rd line) is invalid as the text is correct as it appears in the final PTC document Fix as stated below: · 2.1.2.4.2.6: 2nd paragraph, 1st line: Replace "one" with "once" · 2.1.2.5.3.8: Point 5, 3rd line: Replace "....that is required that.... " with "....that it is required that....." Revised Text8: 2.1.2.4.2.6: 2nd paragraph The operation unregister_instance should be called just once per instance, regardless of how many times register_instance was called for that instance. 2.1.2.5.3.8: Point 5 If PRESENTATION access_scope is GROUP and ordered_access is set to TRUE, then the returned collection contains at most one sample. The difference in this case is due to the fact that it is required that the application is able to read samples belonging to different DataReader objects in a specific order. Disposition8: Resolved Summary9: 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 in an initialization phase..." Resolution9: Fix Section 2.1.4.4 as stated above Revised Text9: Usually the first step is done in an initialization phase, while the others are put in the application main loop. Disposition9: Resolved Summary10: Ref-228 Typo_on_2.1.2.2.1.13 2.1.2.2.1.13 2nd paragraph, 4th line: "filed" should be "field" Resolution10: Fix as stated above Revised Text10: This application data is propagated as a field in the built-in topic and can be used by an application to implement its own access control policy. Disposition10: Resolv
Actions taken:
December 8, 2003: received issue
September 23, 2004: closed issue

Issue 6686: Bad references (data-distribution-ftf)

Click here for this issue's archive.
Source: Real-Time Innovations (Dr. Gerardo Pardo-Castellote, Ph.D., gerardo@rti.com pardo@rti.com)
Nature: Uncategorized Issue
Severity:
Summary: 
[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

Resolution: see below
Revised Text: Summary1: 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 Resolution1: Replace SubscriberFactory with DomainParticipant in said sections. Revised Text1: · Section 2.1.5 Built-in Topics The built-in data-readers all belong to a built-in Subscriber. This subscriber can be retrieved by using the method get_builtin_subscriber provided by the DomainParticipant. · Section 2.1.6.2.1 SubscriptionView The first part of Figure 22 shows the Subscriber's and the DataReader's creation by means of the DomainParticipant. · Section 2.1.6.2.2 Notifications via Conditions and Wait-Sets The first part of Figure 22 shows the Subscriber's and the DataReader's creation by means of the DomainParticipant. Disposition1: Resolved Disposition1: Resolved Summary2: Ref-71 Bad_reference_to_CORBA_PIM Section 2.2.1. 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 ..." Resolution2: · Section 2.2.1 Overview and Design Rationale Replace "PIM" with "PSM" Revised Text2: The CORBA PSM is provided by means of the IDL that defines the interface an application can use to interact with the Service. Disposition2: Resolved Summary3: 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 Resolution3: Replace all references to appendix A with references to appendix B Revised Text3: Disposition3: Resolved
Actions taken:
December 8, 2003: received issue
September 23, 2004: closed issue

Issue 6687: Missing operations to allow the navigation described in the PIM (data-distribution-ftf)

Click here for this issue's archive.
Source: Real-Time Innovations (Dr. Gerardo Pardo-Castellote, Ph.D., gerardo@rti.com pardo@rti.com)
Nature: Uncategorized Issue
Severity:
Summary: 
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.

Resolution: see below
Revised Text: Summary1: 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). Resolution1: Add a get_datareader() operation to the ReadCondition. This operation should take no arguments and return a DataReader This corresponds to the following changes: · add the following line to the IDL for the ReadCondition interface in section 2.2.3 (CORBA PSM IDL) DataReader get_datareader (); · add the operation get_datareader to the table in section 2.1.2.5.8 · add the subsection 2.1.2.5.8.1 with the text below: "2.1.2.5.8.1 get_datareader This operation returns the DataReader associated with the ReadCondition. Note that there is exactly one DataReader associated with each ReadCondition." Revised Text1: Changes in PIM · In section 2.1.2.5.8 ReadCondtion Class · in the table, add the following operation get_datareader DataReader · add a new subsection, with the following content: "2.1.2.5.8.1 get_datareader This operation returns the DataReader associated with the ReadCondition. Note that there is exactly one DataReader associated with each ReadCondition." Changes in IDL · in section 2.2.3 (CORBA PSM IDL) · interface ReadCondition, · add the following operation DataReader get_datareader(); Disposition1: Resolved Summary2: 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). Resolution2: Add a get_entity() operation to StatusCondition. This operation should take no arguments and return a Entity. This corresponds to the following changes: · add the following line to the IDL for the StatusCondition interface in section 2.2.3 (CORBA PSM IDL) Entity get_entity(); · add the operation get_entity to the table in section 2.1.2.1.9 · add the subsection 2.1.2.1.9.2 with the text below: "2.1.2.1.9.2 get_entity This operation returns the Entity associated with the StatusCondition. Note that there is exactly one Entity associated with each StatusCondition." Revised Text2: Changes in PIM · In section 2.1.2.1.9 · in the table, add the following operation get_entity Entity · add a new subsection with the following content: "2.1.2.1.9.2 get_entity This operation returns the Entity associated with the StatusCondition. Note that there is exactly one Entity associated with each StatusCondition." Changes in IDL · In section 2.2.3 DCPS PSM : IDL · interface StatusCondition · add the following operation: Entity get_entity(); Disposition2: Resolved Summary3: 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). Resolution3: Add a get_topicdescription operation to DataReader. This operation should take no arguments and return a TopicDescription. This corresponds to the following changes: · add the following line to the IDL for the DataReader interface in section 2.2.3 (CORBA PSM IDL) TopicDescription get_topicdescription(); · add the operation get_ topicdescription to the DataReader table in section 2.1.2.5.3 · add the subsection 2.1.2.5.3.15 with the text below: "2.1.2.5.3.15 get_ topicdescription This operation returns the TopicDescription associated with the DataReader. This is the same TopicDescription that was used to create the DataReader." Revised Text3: Changes in PIM · In section 2.1.2.5.3 DataReader · in the table, add the following operation get_topicdescription TopicDescription · add a new subsection with the following content: "2.1.2.5.3.15 get_ topicdescription This operation returns the TopicDescription associated with the DataReader. This is the same TopicDescription that was used to create the DataReader." Changes in IDL · In section 2.2.3 DCPS PSM : IDL · interface DataReader · add the following operation: TopicDescription get_topicdescription(); Disposition3: Resolved Summary4: 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). Resolution4: Add a get_topic() operation to DataWriter. This operation should take no arguments and return a Topic. Revised Text4: Changes in PIM · In section 2.1.2.4.2 DataWriter · in the table, add the following operation get_topic Topic · add a new subsection with the following content: "2.1.2.5.3.15 get_ topic This operation returns the Topic associated with the DataWriter. This is the same Topic that was used to create the DataWriter " Changes in IDL · In section 2.2.3 DCPS PSM : IDL · interface DataWriter · add the following operation: Topic get_topic(); Disposition4: Resolved Summary5: 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) Resolution5: Add a get_subscriber operation on DataReader; this operation takes no parameter and returns a Subscriber. This corresponds to the following changes: · add the following line to the IDL for the DataReader interface in section 2.2.3 (CORBA PSM IDL) Subscriber get_subscriber(); · add the operation get_subscriber to the DataReader table in section 2.1.2.5.3 · add the subsection 2.1.2.4.2.16 with the text below: "2.1.2.5.3.16 get_subscriber This operation returns the Subscriber to which the DataReader belongs." Add a get_publisher operation on DataWriter operation takes no parameter and returns a Publisher This corresponds to the following changes: · add the following line to the IDL for the DataWriter interface in section 2.2.3 (CORBA PSM IDL) Publisher get_publisher(); · add the operation get_publisher to the DataWriter table in section 2.1.2.4.2 · add the subsection 2.1.2.4.2.16 with the text below: "2.1.2.4.2.16 get_ publisher This operation returns the Publisher to which the DataWriter belongs." Add a get_participant operation on Publisher; this operation takes no parameter and return a Participant. This corresponds to the following changes: · add the following line to the IDL for the Publisher interface in section 2.2.3 (CORBA PSM IDL) DomainParticipant get_participant(); · add the operation get_participant to the Publisher table in section 2.1.2.4.1 · add the subsection 2.1.2.4.1.12 with the text below: "2.1.2.4.1.12 get_participant This operation returns the DomainParticipant to which the Publisher belongs." Add a get_participant operation on Subscriber; this operation takes no parameter and return a Participant. This corresponds to the following changes: · add the following line to the IDL for the Subscriber interface in section 2.2.3 (CORBA PSM IDL) DomainParticipant get_participant(); · add the operation get_participant to the Subscriber table in section 2.1.2.5.2 · add the subsection 2.1.2.5.2.13 with the text below: "2.1.2.5.3.13 get_participant This operation returns the DomainParticipant to which the Subscriber belongs." Add a get_participant operation on TopicDescription; this operation takes no parameter and return a Participant. This corresponds to the following changes: · add the following line to the IDL for the TopicDescription interface in section 2.2.3 (CORBA PSM IDL) DomainParticipant get_participant(); · add the operation get_participant to the TopicDescription table in section 2.1.2.3.1 · add the subsection 2.1.2.3.1.1 with the text below: 2.1.2.3.1.1get_participant This operation returns the DomainParticipant to which the TopicDescription belongs. Note: 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. Revised Text5: Changes in PIM · In section 2.1.2.5.3 DataReader · in the table, add the following operation get_subscriber Subscriber · add a new subsection with the following content: "2.1.2.5.3.16 get_subscriber This operation returns the Subscriber to which the DataReader belongs." · In section 2.1.2.4.2 DataWriter · in the table, add the following operation get_publisher Publisher · add a new subsectionwith the following content: "2.1.2.4.2.16 get_ publisher This operation returns the Publisher to which the DataWriter belongs." · In section 2.1.2.4.1 Publisher · in the table, add the following operation get_participant DomainParticipant · add a new subsection with the following content: "2.1.2.4.1.12 get_participant This operation returns the DomainParticipant to which the Publisher belongs." · In section 2.1.2.5.2 Subscriber · in the table, add the following operation get_participant DomainParticipant · add a new subsection with the following content: "2.1.2.5.3.13 get_participant This operation returns the DomainParticipant to which the Subscriber belongs Changes in IDL · In section 2.2.3 DCPS PSM : IDL · interface DataReader · add the following operation: Subscriber get_subscriber(); · interface DataWriter · add the following operation: Publisher get_publisher(); · interface Publisher · add the following operation: DomainParticipant get_participant(); · interface Subscriber · add the following operation: DomainParticipant get_participant(); Disposition5: Resolved
Actions taken:
December 8, 2003: received issue
September 23, 2004: closed issue

Discussion: 




Issue 6705: ref-1001: section 3.1.1 (editorial                                                                                                                                                                      (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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"



Resolution: see below

Revised Text: Revised Text:
·	Section 3.1.1 Overview and Design Rationale
		The purpose of this layer is to provide more direct access to the exchanged data, seamlessly integrated with the native-language constructs..


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6706: ref-1002: section 3.1.2.1 (editorial                                                                                                                                                                    (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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)



Resolution: see below

Revised Text: Resolution: 
Restore the wording and footprint as it was in version V67 .
Concrete Changes are as follows: 
Replace the text section 3.1.2.1 starting from "A DLRL object has at least one shared attribute.." until the next section (3.1.3.2) with the following text (refer to convenience document for precise format):
"A DLRL object has at least one shared attribute. Shared attributes are typed and can be either mono-valued or multi-valued:
·	Mono-valued:
·	of a simple type:
·	basic-type (long, short, char, string, etc.);
·	enumeration-type;
·	simple structure  
·	reference to a DLRL object.
For these mono-valued attributes, type enforcement is as follows:
·	strict type equality for simple types;
·	equality based on inclusion for reference to a DLRL object (i.e., a reference to a derived object can be placed in a reference to a base object).
·	Multi-valued (collection-based):
·	two collection basis of homogeneously-typed items:
·	a list (ordered with index);
·	a map (access by key).
Type enforcement for collection elements is as follows:
·	strict type equality for simple types;
·	equality based on type inclusion for references to DLRL objects (i.e., a reference to a derived object can be placed in a collection typed for base objects).
DLRL will manage DLRL objects in a cache (i.e., two different references to the same object - an object with the same identity - will actually point to the same memory location).
Object identity is given by an oid (object ID) part of any DLRL object."
Revised Text:

A DLRL object has at least one shared attribute. Shared attributes are typed2 and can be
either mono-valued or multi-valued:
o Mono-valued:
o of a simple type:
o basic-type (long, short, char, string, etc.);
o enumeration-type;
o simple structure3
o reference to a DLRL object.
For these mono-valued attributes, type enforcement is as follows:
o strict type equality for simple types;
o equality based on inclusion for reference to a DLRL object (i.e., a reference to a derived object can be placed in a reference to a base object).
o Multi-valued (collection-based):
o two collection basis of homogeneously-typed items:
o a list (ordered with index);
o a map (access by key).
Type enforcement for collection elements is as follows:
o strict type equality for simple types;
o equality based on type inclusion for references to DLRL objects (i.e., a referenceto a derived object can be placed in a collection typed for base objects).


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6707: ref-1003: Section 3.1.3.2 (editorial)                                                                                                                                                                   (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

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



Resolution: see below

Revised Text: ·	Section 3.1.3.2.2 Associations

Note - Embedded structures are restricted to the ones that can be mapped simply
at the DCPS level. For more complex ones, component objects (i.e., objects linked by
a composition relation) may be used.


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6708: ref-1004: Section 3.1.3.3 Metamodel (clarification)                                                                                                                                                     (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Clarification

Severity: 

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



Resolution: see below

Revised Text: Resolution: 
Add a clarification sentence (at the end of the first paragraph of the section page 3.4):
Revised Text:
Changes in PIM
·	At the end of section 3.1.3.3 Metamodel
·	add the following paragraph
" This metamodel is given for explanation purpose. This specification does not require that it is implemented as such."


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6709: ref-1005: figure 3.2 (editorial)                                                                                                                                                                        (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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



Resolution: Correct the figure

Revised Text: 

Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6710: ref-1006: Page 3.11 (editorial)                                                                                                                                                                         (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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



Resolution: see below

Revised Text: Resolution: 
Correct the footprint for those words.
Revised Text:
·	Section 3.1.4.4 Metamodel with Mapping Information
The three constructs that need  added information related to the structural mapping are Class, Attribute and Relation.
·	Section 3.1.4.4.2 MonoAttribute
o key_fields is the name of the fields that make the key in this topic (1 or 2 depending
on the Class definition);


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6711: ref-1007: Section 3.1.6.3.4 CacheListener (editorial)                                                                                                                                                   (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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.



Resolution: see below

Revised Text: Resolution: 
Correct the textual description to align on the table.
Revised Text:
·	In section 3.1.6.3.4 CacheListener,
·	In the paragraph after the table, starting with "It provides the following methods"
·	First bullet, replace first word with: "on_begin_updates"
·	Second bullet, replace first word with: "on_end_updates"
Disposition:	Resolved 


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6712: ref-1008: Bad annex reference (editorial)                                                                                                                                                               (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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: see above

Revised Text: 

Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue


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





Issue 6713: ref-1009: Section 3.2.3.2 IDL Model description of the example                                                                                                                                          (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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



Resolution: see below

Revised Text: Resolution: 
Update the valuetype Track in section 3.2.3.2  with the two missing fields:
and add the valuetype Track3D and valuetype Radar.
Revised Text:
Changes
·	Section 3.2.3.2 IDL Model description
·	Modify valuetype Track to be:
valuetype Track : DLRL::ObjectRoot {
    public double       x;
    public double       y;
    public stringStrMap comments;
    public long         w; 
    public RadarRef     a_radar;
    };
·	Add (after valuetype Track):
valuetype Track3D : Track {
    public double       z;
};
valuetype Radar : DLRL::ObjectRoot {
    public TrackList    tracks;
};


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6714: ref-1010: Section 3.2.3.3 XML Model Tags of the example                                                                                                                                                 (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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



Resolution: see below

Revised Text: Resolution: 
Restore the contents as it was in version V67 and introduce a void line to keep it separated from the introduction
Revised Text:
Changes
·	Insert empty line after the first paragraph in section 3.2.3.3 before the XML starts
·	Append the following at the end of the XML (the XML that precedes figure 3-9 in section 3.2.3.3) and use for the XML, the same paragraph format used for IDL:
<local name="w"/>
   </classMapping>
   <classMapping name="Track3D">
      <mainTopic name="TRACK-TOPIC" classField="CLASS" oidField="OID"/>
      <extensionTopic name="TRACK3D-TOPIC" classField="CLASS" oidField="OID"/>
      <monoAttribute name="z">
         <valueField>Z</valueField>
      </monoAttribute>
   </classMapping>
   <classMapping name="Radar">
      <mainTopic name="RADAR-TOPIC" oidField="OID"/>
      <multiRelation name="tracks">
         <multiPlaceTopic name="RADARTRACKS-TOPIC" oidField="RADAR-OID" indexField="INDEX"/>
         <valueKey classField="TRACK-CLASS" oidField="TRACK-OID"/>
      </multiRelation>
   </classMapping>
   <associationDef>
      <relation class="Track" attribute="a_radar"/>
      <relation class="Radar" attribute="tracks"/>
   </associationDef>
</Dlrl> 


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6715: ref-1011: Section 3.2.3.3 Introduction to figure 3.9 (editorial)                                                                                                                                        (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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



Resolution: Correct the footprint

Revised Text: 

Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6716: ref-1012: Section 3.2.3.3 Simplified XML of the example)                                                                                                                                                (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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:"



Resolution: see below

Revised Text: Resolution: 
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:"
Append the missing part of the XML, to the existing one.
 following XML at the end of the existing XML:
<local name="w"/>
   </classMapping>
   <associationDef>
      <relation class="Track" attribute="a_radar"/>
      <relation class="Radar" attribute="tracks"/>
   </associationDef>
</Dlrl>
Revised Text:
Changes
·	In section 3.2.3.3, just before the XML, 
·	change the last sentence of the introduction to:
" 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:"
·	Append the following XML, at the end of the existing one:
<local name="w"/>
   </classMapping>
   <associationDef>
      <relation class="Track" attribute="a_radar"/>
      <relation class="Radar" attribute="tracks"/>
   </associationDef>
</Dlrl>


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6717: ref-1013: Section 3.1.6.3.9 Table for ObjectQuery (editorial)                                                                                                                                           (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

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



Resolution: see below

Revised Text: Resolution: 
Change the type of the attribute "parameters" from "string[}" to "string []" 
Revised Text:
·	In section 3.1.6.3.9  ObjectQuery
·	In the table, change the entry for the attribute "parameters to the following
parameters	string []


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6718: ref-1014: Page 3-10, figure 3-2 min_topic (editorial)                                                                                                                                                   (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

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



Resolution: correct the figure

Revised Text: 

Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6719: ref-1015: Page 3-62 manual edition (editorial)                                                                                                                                                          (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

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



Resolution: see below

Revised Text: Resolution: 
Change the sentence to the following: "It should be noted that XML is not suitable for manual editing"
Revised Text:
·	In section 3.2.3.3, after the XML
·	replace the first sentence:
" It should be noted that XML is not suitable for manual edition."
		with:
" It should be noted that XML is not suitable for manual editing."


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6720: ref-1016: Page 3-65 t2 (editorial)                                                                                                                                                                      (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

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



Resolution: see below

Revised Text: Resolution: 
Apply those 3 changes
Revised Text:
·	Section 3.2.3.5 Code Example
·	Replace
t2->a-radar->put(r1);// modifies r1->tracks accordingly
t3->z(3000.0);
t2->a-radar->put(r1);// modifies r1->tracks accordingly
		
with

t2->a_radar->put(r1);// modifies r1->tracks accordingly
t2->z(3000.0);
t2->a_radar->put(r1);// modifies r1->tracks accordingly



Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6721: ref-1017: Section 3.1.4.4.2 topic (editorial                                                                                                                                                            (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

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



Resolution: see below

Revised Text: Resolution: 
Correct the wording.
Revised Text:
·	In section 3.1.4.4.2  MonoAttribute
·	first bullet, replace " Class::topic" with " Class::main_topic"
Disposition:	Resolved 


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6722: ref-1018: Name of the methods for ObjectListener (editorial)                                                                                                                                            (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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)



Resolution: see below

Revised Text: Resolution: 
Apply everywhere the names "on_object-created", "on_object_modified" and "on_object_deleted".
Revised Text:
Changes
·	In section 3.1.6.3.6, 
·	in the table;
·	replace "on_created_object" with "on_object_created"
·	replace "on_modified_object" with "on_object_ modified"
·	replace "on_deleted_object" with "on_object_ deleted"
·	In Figure 3-4 ObjectListener. Replace "on_new_object" with "on_object_created


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6723: ref-1019: Name of the ObjectRoot::clone method (editorial)                                                                                                                                              (data-distribution-ftf)

Click here for this issue's archive.


Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com)

Nature: Uncategorized Issue

Severity: 

Summary: 
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)



Resolution: see below

Revised Text: Resolution: 
Correct the text from " clone_object" to "clone" (everywhere else, the method is named "clone").
Revised Text:
Changes
·	In section 3.1.6.3.11
·	In the text starting with "it offers methods"
·	first bullet, replace the first sentence:
"create a copy of the object and attach it to a CacheAccess (clone_object)"
		with
"create a copy of the object and attach it to a CacheAccess (clone)"
Disposition:	Resolved


Actions taken:

December 17, 2003: received issue

September 23, 2004: closed issue



Issue 6729:  Additional_communication_paradigms                                                                                                                                                                     (data-distribution-ftf)

Click here for this issue's archive.


Nature: Enhancement

Severity: Significant

Summary: 
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. 



Resolution: 

Revised Text: 

Actions taken:

December 18, 2003: received issue

September 23, 2004: closed no change


Discussion: 
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.




Issue 6730: Attributes_on_a_topic_description                                                                                                                                                                       (data-distribution-ftf)

Click here for this issue's archive.


Nature: Enhancement

Severity: Significant

Summary: 
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.


Resolution: see below

Revised Text: Resolution: 
Resolution of this issue as stated would necessitate the use of value-types or else extensions to the IDL language to support the ("attribute-name", "attribute-value") pairs. However, the specification can be modified to allow the application to implement this in "user-code".
The FTF resolved to add two facilities to support this:
·	A QoS similar to USER_DATA on the Topic could be used by SOSCOE to "stuff" the name-value pairs. 
·	Additional listener operations DataReaderListener::on_remote_publication_match and DataWriterListener::on_remote_subscription_match would be called when the infrastructure discovers a match between the local reader/writer entity and the remote writer/reader entities. These listeners would have access to the QoS of the local and remote entities and use the information stored in the TOPIC_DATA to implement any matching policy desired by the SOSCOE layer. In particular they could use the ignore_xxx operations to prevent the association between the local reader/writer entity and the remote writer/reader entities.
The resolution of issue 7066 introduced the TOPIC_DATA QoS on topic containing a octet sequence which can be used for this purpose. So to resolve this issue it is only necessary to introduce the aforementioned listeners.
Revised Text:
Changes in PIM
·	Section 2.1.2.2.3 DomainParticipantListener Interface
·	DomainParticipantListener table
·	Add the following rows:

on_publication_match		void
	the_writer	DataWriter
	status	PublicationMatchStatus
on_subscription_match		void
	the_reader 	DataReader
	status	SubscriptionMatchStatus

·	Section 2.1.2.4.4 DataWriterListener Interface
·	DataWriterListener table
·	Add the following rows:
on_publication_match		
	the_writer	DataWriter
	status	PublicationMatchStatus
·	Section 2.1.2.5.7 DataReaderListener Interface
·	DataReaderListener table
·	Add the following rows:
on_subscription_match		
	the_reader 	DataReader
	status	SubscriptionMatchStatus
·	Add after paragraph "Since a DataReader is a kind of Entity …
The operation on_subscription_match is intended to inform the application of the discovery of DataWriter entities that match the DataReader . Some implementations of the service may not propagate this information. In that case the DDS specification does not require this listener operation to be called.
·	Section 2.1.4.1 Communication Status
·	Status table. Modify it adding rows for SUBSCRIPTION_MATCH and PUBLICATION_MATCH. The resulting table follows:
Entity	Status Name	Meaning
Topic	INCONSISTENT_TOPIC	Another topic exists with the same name but different characteristics.
Subscriber	DATA_ON_READERS	New information is available.
DataReader	SAMPLE_REJECTED	A (received) sample has been rejected.
	LIVELINESS_CHANGED	The liveliness of one or more DataWriter that were writing instances read through the DataReader has changed. Some DataWriter have become "active" or "inactive".
	REQUESTED_DEADLINE_MISSED	The deadline that the DataReader was expecting through its QosPolicy DEADLINE was not respected for a specific instance.
	REQUESTED_INCOMPATIBLE_QOS	A QosPolicy value was incompatible with what is offered.
	DATA_AVAILABLE	New information is available.
	SAMPLE_LOST	A sample has been lost (never received).
	SUBSCRIPTION_MATCH	The DataReader has found a DataWriter that matches the Topic and has compatible QoS.
DataWriter	LIVELINESS_LOST	The liveliness that the DataWriter has committed through its QosPolicy LIVELINESS was not respected; thus DataReader entities will consider the DataWriter as no longer "active".
	OFFERED_DEADLINE_MISSED	The deadline that the DataWriter has committed through its QosPolicy DEADLINE was not respected for a specific instance.
	OFFERED_INCOMPATIBLE_QOS	A QosPolicy value was incompatible with what was requested.
	PUBLICATION_MATCH	The DataWriter has found DataReader that matches the Topic and has compatible QoS.
·	Status contents table. Modify it adding rows for PublicationMatchStatus and SubscriptionMatchStatus:
PublicationMatchStatus	Attribute meaning
total_count	Total cumulative count the concerned DataWriter discovered a "match" with a DataReader. That is, it found a DataReader for the same Topic with a requested QoS that is compatible with that offered by the DataWriter.
total_count_change	The change in total_count since the last time the listener was called or the status was read.
last_subscription_handle	Handle to the last DataReader that matched the DataWriter causing the status to change.
SubscriptionMatchStatus	Attribute meaning
total_count	Total cumulative count the concerned DataReader discovered a "match" with a DataWriter. That is, it found a DataWriter for the same Topic with a requested QoS that is compatible with that offered by the DataReader.
total_count_change	The change in total_count since the last time the listener was called or the status was read.
last_publication_handle	Handle to the last DataWriter that matched the DataReader causing the status to change.
·	Update Figure 2-17 with additional operations on the listeners:
·	The resulting figure is:
 
·	Section 2.1.2.4.2 DataWriter Class
·	DataWriter table
·	Add operation:
get_matched_subscription_data		ReturnCode_t
	inout: subscription_data	SubscriptionBuiltinTopicData
	subscription_hand le	InstanceHandle_t
·	Add Section 2.1.2.4.2.20 
2.1.2.4.2.20 get_matched_subscription_data
This operation retrieves information on a subscription that is currently "associated" with the DataWriter; that is, a subscription with a matching Topic and compatible QoS that the application has not indicated should be "ignored" by means of the DomainParticipant ignore_subscription operation.
The subscription_handle must correspond to a subscription currently associated with the DataWriter, otherwise the operation will fail and return PRECONDITION_NOT_MET. The operation get_matched_subscriptions to find the subscriptions that are currently matched with the DataWriter.
The operation may also fail if the infrastructure does not hold the information necessary to fill in the subscription_data. In this case the operation will return UNSUPPORTED.
·	Section 2.1.2.4.2 DataReader Class
·	DataWriter table
·	Add operation:
get_matched_publication_data		ReturnCode_t
	inout:publication_data	PublicationBuiltinTopicData
	publication_handle	InstanceHandle_t
·	Add Section 2.1.2.5.3.22
2.1.2.5.3.22 get_matched_publication_data
This operation retrieves information on a publication that is currently "associated" with the DataReader; that is, a publication with a matching Topic and compatible QoS that the application has not indicated should be "ignored" by means of the DomainParticipant ignore_publication operation.
The publication_handle must correspond to a publication currently associated with the DataReader otherwise the operation will fail and return PRECONDITION_NOT_MET. The operation get_matched_publications to find the publications that are currently matched with the DataReader.
The operation may also fail if the infrastructure does not hold the information necessary to fill in the publication_data. In this case the operation will return UNSUPPORTED.
Changes in IDL
·	After definition of InstanceHandle_t add:
 typedef sequence<InstanceHandle_t> InstanceHandleSeq;
·	At the end of the StatusKind definitions add:
const StatusKind PUBLICATION_MATCH_STATUS = 0x0001 << 13;
 const StatusKind SUBSCRIPTION_MATCH_STATUS  = 0x0001 << 14; 
·	Add ( after struct RequestedIncompatibleQosStatus):
 
struct PublicationMatchStatus {
	long total_count;
	long total_count_change;
	InstanceHandle_t last_publication_handle;
};
 struct SubscriptionMatchStatus {
	long total_count;
	long total_count_change;
	InstanceHandle_t last_subscription_handle;
}; 
·	Interface DataWriterListener
·	Add operation:
void on_publication_match(in DataWriter writer, in PublicationMatchStatus status);
·	Interface DataReaderListener
·	Add operation:
void on_subscription_match(in DataReader reader, in SubscriptionMatchStatus status);
·	Interface DataWriter
·	Add operations:
ReturnCode_t get_matched_subscription_data(inout SubscriptionBuiltinTopicData subscription_data, in InstanceHandle_t subscription_handle);
·	Interface DataReader
·	Add operations:
ReturnCode_t get_matched_publication_data(inout PublicationBuiltinTopicData publication_data, in InstanceHandle_t publication_handle);
Disposition:	Resolved 


Actions taken:

December 18, 2003: received issue

September 23, 2004: closed issue



Issue 6731: Extension_to_the_partition_qos                                                                                                                                                                          (data-distribution-ftf)

Click here for this issue's archive.


Nature: Enhancement

Severity: Significant

Summary: 
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). 



Resolution: see below

Revised Text: Resolution: 
Similar to issue 6730 resolution of this issue as stated would require the use of value-types or else extensions to IDL to express name-value pairs. However it is possible to offer facilities that would allow the implementation of this feature in application code.
The FTF resolved to add a GROUP_DATA QoS to Publisher and Subscriber. The contents are an octet sequence (like USER_DATA QoS) and  are propagated with built-in topics for DataWriter/DataReader. The application can examine the GROUP_DATA and implement the customized logic using the same facilities introduced to address issue 6730.
Revised Text:
Changes in PIM
·	Section 2.1.3 Supported QoS
·	QoS Table
·	Add policy "GROUP_DATA"
QosPolicy	Value	Meaning	Concerns	RxO	Changeable
GROUP_DATA	a sequence of octets	User data not known by the middleware, but distributed by means of built-in topics (cf.  Section ).The default value is an empty (zero- sized) sequence.	Publisher, Subscriber	No	Yes
·	Add section 2.1.3.3 (changes numbers of subsections that follow)
2.1.3.3 GROUP_DATA
The purpose of this QoS is to allow the application to attach additional information to the created Publisher or Subscriber.  The value of the GROUP_DATA is available to the application on the DataReader and DataWriter entities and is propagated by means of  the built-in topics.  
This QoS can be used by an application combination with the  DataReaderListener  and DataWriterListener to implement matching policies similar to those of the PARTITION QoS except for the decision can be made based on an application-defined policy.
·	Section 2.1.5 Built-in Topics
·	Table with QoS of built-in Subscriber and DataReader objects
·	Add row:
GROUP_DATA	<unspecified>

·	Table with types for built-in topics
·	For Topic name= "DCPSPublication" add row:
group_data	GroupDataQosPolic y	Policy of the Publisher to which the DataWriter belongs.

·	For Topic name= "DCPSSubscription" add row:
group_data	GroupDataQosPolic y	Policy of the Subscriber to which the DataReader belongs.
Changes in IDL
·	Add (after const string TOPICDATA_QOS_POLICY_NAME = ""TopicData";)
const string GROUPDATA_QOS_POLICY_NAME = "GroupData";
·	Add (after const QosPolicyId_t TOPICDATA_QOS_POLICY_ID= 18";)
const QosPolicyId_t GROUPDATA _QOS_POLICY_ID = 19;
·	Add (after struct TopicDataQosPolicy { … };)
    struct GroupDataQosPolicy {
		sequence<octet> value;
    };
·	struct PublisherQos
·	Add member:
GroupDataQosPolicy  group_data;
·	struct SubscriberQos
·	Add member:
GroupDataQosPolicy  group_data;
·	struct PublicationBuiltinTopicData
·	Add member:
GroupDataQosPolicy    group_data;
·	struct SubscriptionBuiltinTopicData
·	Add member:
GroupDataQosPolicy    group_data;


Actions taken:

December 18, 2003: received issue

September 23, 2004: closed issue



Issue 6732:  Extension_to_the_query_language                                                                                                                                                                        (data-distribution-ftf)

Click here for this issue's archive.


Nature: Enhancement

Severity: Significant

Summary: 
Issue# 2035 Extension_to_the_query_language Issue [Boeing SOSCOE] ? SOSCOE has a need to allow function expressions to be added to the query language ? 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. Proposal [Boeing] ? Extend the query language to allow user defined function expressions ? Extend the query language to allow user defined structured types 



Resolution: 

Revised Text: 

Actions taken:

December 18, 2003: received issue


Discussion: 
Discussion: 
The FTF recognizes this would be a useful facility. However, the FTF could not find suitable resolution within the time-frame of the FTF and therefore resolved to defer the issue to a future F/RTF or revision.





Issue 6733: Attributes_on_the_data                                                                                                                                                                                  (data-distribution-ftf)

Click here for this issue's archive.


Nature: Enhancement

Severity: Significant

Summary: 
Attributes_on_the_data Issue [Boeing SOSCOE] ? The DDS API forces the data to be written to be encapsulated into a single IDL structure. Moreover IDL-generated structures do not support pointers to other structures. ? These limitations are constraining the kinds of things that a layer such as SOSCOE can do. For example, it would be desirable to allow the DDS DataWriter to filter or perform other actions on information that is not “part of the data”. Not “being part of the data” means the attributes: • Are propagated along with the message (1-to-1 relationship) to the reader. • May be used for filtering, or intercepted by layers above DDS (e.g. SOSCOE). • Do not get passed to the read or take calls ? The problem is that since the DataWriter takes a single “compacted” data-structure, any additional information, whether introduced by the user-app or the SOSCOE layer must be somehow copied into the data and thus force the introduction of new data-types. ? In other words it would be desirable for DDS so provide some hook that would allow a user or a layer such as SOSCOE to add additional information to the “user-level” data that is then used by DDS to filter on. The filtering would then occur on t