Issue 7964: no specific mention of interoperability in DDS 04-04-12 standard proposal
Issue 7965: DDS: DCPS generated interface FooTypeSupport
Issue 7966: DDS: DCPS - define the term "plain data structures"
Issue 7974: 2.1.3.20 WRITER_DATA_LIFECYCLE, itemized list, first bullet
Issue 7975: DDS 04-04-12 para. 2.1.1.1 Format and conventions
Issue 7976: DDS 04-04-12 Appendix B, C
Issue 8354: Typographical and grammatical errors
Issue 8355: Spelling inconsistencies between the PIM and IDL PSM
Issue 8358: Operation DataWriter::register
Issue 8359: (T#4) Typo in section 2.1.2.4.2.10 (write) and section 2.1.2.4.12 (dispose)
Issue 8360: Typo in section 2.1.2.5.2.5
Issue 8361: Default value for READER_DATA_LIFECYCLE
Issue 8362: Incorrect reference to USER_DATA on TopicQos
Issue 8363: No mention of DESTINATION_ORDER on DataWriterQos
Issue 8364: Formal parameter name improvement in IDL
Issue 8365: Spell fully the names for the DataReader operations
Issue 8366: Missing operations on DomainParticipantFactory
Issue 8367: T#18,24,) Missing operations and attributes
Issue 8368: (T#28) Typographical and grammatical errors
Issue 8369: (T#29) Missing operations to Topic class
Issue 8370: Formal parameter name change in operations of ContentFilteredTopic
Issue 8371: (T#30) Ambiguous description of TOPIC_DATA
Issue 8372: Confusing description of behavior of Publisher::set_default_datawriter_qos
Issue 8373: (T#33) Clarification in use of set_listener operation
Issue 8374: Missing description of DomainParticipant::get_domain_id
Issue 8375: (T#41) Default value for RELIABILITY max_blocking_time
Issue 8376: (T#42) Behavior when condition is attached to WaitSet multiple times
Issue 8377: Explicit mention of static DomainParticipantFactory::get_instance operation
Issue 8378: (T#45) Clarification of syntax of char constants within query expressions
Issue 8379: (T#52) Allow to explicitly refer to the default QoS
Issue 8380: (T#54) Performance improvement to WaitSet
Issue 8381: (T#55) Modification to how enumeration values are indicated in expressions
Issue 8382: (T#56) Return values of Waitset::detach_condition
Issue 8383: (T#57) Enable status when creating DomainParticipant
Issue 8384: Add autopurge_disposed_samples_delay to READER_DATA_LIFECYCLE QoS
Issue 8388: (R#106b) Parameter passing convention of Subscriber::get_datareaders
Issue 8389: (R#107) Missing Topic operations in IDL PSM
Issue 8390: (R#109) Unused types in IDL
Issue 8391: Incorrect field name for USER_DATA, TOPIC_DATA, and GROUP_DATA
Issue 8392: R#112) Incorrect SampleRejectedStatusKind constants
Issue 8393: R#114) Operations should not return void
Issue 8394: R#115) Destination order missing from PublicationBuiltinTopicData
Issue 8395: TransportPriority QoS range does not specify high/low priority values
Issue 8396: (R#119) Need lookup_instance method on reader and writer
Issue 8397: (R#120) Clarify use of DATAREADER_QOS_USE_TOPIC_QOS
Issue 8398: (R#122) Missing QoS dependencies in table
Issue 8399: Need an extra return code: ILLEGAL_OPERATION
Issue 8417: (R#124) Clarification on the behavior of dispose
Issue 8418: (R#125) Additional operations that can return RETCODE_TIMEOUT
Issue 8419: (R#127) Improve PSM mapping of BuiltinTopicKey_t
Issue 8420: Unspecified behavior of DataReader/DataWriter creation w/t mismatched Topic
Issue 8421: (R#130) Unspecified behavior of delete_datareader with outstanding loans
Issue 8422: (R#131) Clarify behavior of get_status_changes
Issue 8423: Incorrect reference to LIVELINESS_CHANGED in DataWriter::unregister
Issue 8424: (R#135) Add fields to PublicationMatchStatus and SubscriptionMatchStatus
Issue 8425: (R#138) Add instance handle to LivelinessChangedStatus
Issue 8426: (R#139) Rename *MatchStatus to *MatchedStatus
Issue 8427: (R#142) OWNERSHIP QoS policy should concern DataWriter and DataReader
Issue 8428: (R#145,146) Inconsistent description of Topic module in PIM
Issue 8429: (R#147) Inconsistent error code list in description of TypeSupport::registe
Issue 8430: (R#152) Extraneous WaitSet::wakeup
Issue 8431: (R#153) Ambiguous SampleRejectedStatus::last_reason field
Issue 8432: (R#154) Undefined behavior if resume_publications is never called
Issue 8531: DTD Error (mainTopic
Issue 8532: get_all-topic_names operation missing on figure 3-4
Issue 8533: Naming inconsistencies (IDL PSM vs. PIM) for ObjectHome operations
Issue 8534: Naming inconsistencies (IDL PSM vs. PIM) for Cache operation
Issue 8535: Bad cardinality on figure 3-4
Issue 8536: ReadOnly exception on clone operations
Issue 8537: Wrong definition for FooListener
Issue 8538: Typo CacheUsage instead of CacheAccess
Issue 8539: templateDef explanation contains some mistakes
Issue 8540: DlrlOid instead of DLRLOid in implied IDL
Issue 8541: Parameter wrongly named "object" in implied IDL
Issue 8542: Attach_Listener and detach_listener operations on ObjectHome are untyped
Issue 8543: Remove operations badly put on implied classes
Issue 8545: Behavior of DataReaderListener::on_data_available
Issue 8546: Inconsistent naming for status parameters in DataReader operations.
Issue 8547: (T#23) Syntax of partition strings
Issue 8548: Clarification of order preservation on reliable data reception
Issue 8549: (T#37) Clarification on the value of LENGTH_UNLIMITED constant
Issue 8550: (T#38) request-offered behavior for LATENCY_BUDGET
Issue 8551: (T#46) History when DataWriter is deleted
Issue 8552: (T#47) Should a topic returned by lookup_topicdescription be deleted
Issue 8553: (T#51) Identification of the writer of a sample
Issue 8554: (T#53) Cannot set listener mask when creating an entity
Issue 8555: (T#53) Cannot set listener mask when creating an entity
Issue 8556: (T#59) Deletion of disabled entities
Issue 8557: (T#60) Asynchronous write
Issue 8558: (T#61) Restrictive Handle definition
Issue 8559: (T#62, R#141) Unspecified TOPIC semantics
Issue 8560: (T#65) Missing get_current_time() function
Issue 8561: Read or take next instance, and others with an illegal instance_handle
Issue 8562: (T#69) Notification of unsupported QoS policies
Issue 8567: O#7966) Confusing terminology: "plain data structures"
Issue 8568: (R#104) Inconsistent naming of QueryCondition::get_query_arguments
Issue 8569: (R#115b) Incorrect description of QoS for built-in readers
Issue 8570: (R#117) No way to access Participant and Topic built-in topic data
Issue 8571: (R#126) Correction to DataWriter blocking behavior
Issue 8572: Clarify meaning of LivelinessChangedStatus fields and LIVELINESS le
Issue 8573: (R#133) Clarify meaning of LivelinessLost and DeadlineMissed
Issue 8574: (R#136) Additional operations allowed on disabled entities
Issue 8575: (R#144) Default value for DataWriter RELIABILITY QoS
Issue 8576: (R#150) Ambiguous description of create_topic behavior
Issue 8577: R#178) Unclear behavior of coherent changes when communication interrupted
Issue 8578: R#179) Built-in DataReaders should have TRANSIENT_LOCAL durability
Issue 8579: R#180) Clarify which entities appear as instances to built-in readers
Issue 8580: (R#181) Clarify listener and mask behavior with respect to built-in entitie
Issue 8581: R#182) Clarify mapping of PIM 'out' to PSM 'inout'
Issue 8582: (T#6) Inconsistent name: StatusKindMask
Issue 8775: Page: 2-8
Issue 9478: Inconsistencies between PIM and PSM in the prototype of get_qos() methods
Issue 9479: Inconsistent prototype for Publisher's get_default_datawriter_qos() method
Issue 9480: String sequence should be a parameter and not return value
Issue 9481: Mention of get_instance() operation on DomainParticipantFactory beingstatic
Issue 9482: Improper prototype for get_XXX_status()
Issue 9483: Inconsistent naming in SampleRejectedStatusKind
Issue 9484: OWNERSHIP_STRENGTH QoS is not a QoS on built-in Subscriber of DataReaders
Issue 9485: Consistency between RESOURCE_LIMITS QoS policies
Issue 9486: Blocking of write() call
Issue 9487: Clarify PARTITION QoS and its default value
Issue 9488: Typos in built-in topic table
Issue 9489: Naming of filter_parameters concerning ContentFilteredTopic
Issue 9490: Incorect prototype for FooDataWriter method register_instance_w_timestamp()
Issue 9491: Compatible versus consistency when talking about QosPolicy
Issue 9492: Incorrect mention of INCONSISTENT_POLICY status
Issue 9493: Typos in QoS sections
Issue 9494: Typos in PIM sections
Issue 9495: Clarify ownership with same-strength writers
Issue 9496: Should write() block when out of instance resources?
Issue 9497: Description of set_default_XXX_qos()
Issue 9498: Naming consistencies in match statuses
Issue 9499: delete_contained_entities() on the Subscriber
Issue 9500: Return of get_matched_XXX_data()
Issue 9501: Need INVALID_QOS_POLICY_ID
Issue 9502: Clarify valid handle when calling write()
Issue 9503: Operation dispose_w_timestamp() should be callable on unregistered instance
Issue 9504: Behavior of dispose with regards to DURABILITY QoS
Issue 9505: Typo in copy_from_topic_qos
Issue 9506: Order of parameters incorrect in PSM
Issue 9507: Typo in get_discovered_participant_data
Issue 9508: Operation wait() on a WaitSet should return TIMEOUT
Issue 9509: Example in 2.1.4.4.2 not quite correct
Issue 9510: Non intuitive constant names
Issue 9511: Corrections to Figure 2-19
Issue 9516: Simplify Relation Management
Issue 9517: Cache and CacheAccess should have a common parent
Issue 9518: Object notification in manual update mode required
Issue 9519: ObjectExtent and ObjectModifier can be removed
Issue 9520: Introduce the concept of cloning contracts consistently in specification
Issue 9521: Object State Transitions of Figure 3-5 and 3-6 should be corrected
Issue 9522: Add Iterators to Collection types
Issue 9523: Harmonize Collection definitions in PIM and PSM
Issue 9524: Add the Set as a supported Collection type
Issue 9525: Make the ObjectFilter and the ObjectQuery separate Selection Criterions
Issue 9526: Add a static initializer operation to the CacheFactory
Issue 9527: Make update rounds uninterruptable
Issue 9528: Remove lock/unlock due to overlap with updates_enabled
Issue 9529: Add Listener callbacks for changes in the update mode
Issue 9530: Representation of OID should be vendor specific
Issue 9531: define both the Topic name and the Topic type_name separately
Issue 9532: Merge find_object with find_object_in_access
Issue 9533: Clarify which Exceptions exist in DLRL and when to throw them
Issue 9534: Support sequences of primitive types in DLRL Objects
Issue 9535: manual mapping key-fields of registered objects may not be changed
Issue 9536: Specification does not state how to instantiate an ObjectHome
Issue 9537: Raise PreconditionNotMet when changing filter expression on registered Obje
Issue 9538: PIM description of "get_domain_id" method is missing
Issue 9539: PIM and PSM contradicting wrt "get_sample_lost_status" operation
Issue 9540: Small naming inconsistentcies between PIM and PSM
Issue 9541: Unlimited setting for Resource limits not clearly explained
Issue 9542: Inconsistent PIM/PSM for RETCODE_ILLEGAL_OPERATION
Issue 9543: Resetting of the statusflag during a listener callback
Issue 9544: Incorrect description of enable precondition
Issue 9545: invalid reference to delete_datareader
Issue 9546: Clarify the meaning of locally
Issue 9548: Missing autopurge_disposed_sample_delay
Issue 9549: Illegal return value register_instance
Issue 9550: Typo in section 2.1.2.5.1
Issue 9551: Extended visibility of instance state changes
Issue 9552: Clarify notification of ownership change
Issue 9553: read/take_next_instance()
Issue 9554: instance resource can be reclaimed in READER_DATA_LIFECYCLE QoS section
Issue 9555: String sequence should be a parameter and not return value
Issue 7964: no specific mention of interoperability in DDS 04-04-12 standard proposal (data-distribution-rtf)
Click here for this issue's archive.
Source: Daimler AG (Mr. Oliver M. Kellogg, oliver.kellogg@eads.com Oliver.Kellogg@t-online.de)
Nature: Uncategorized Issue
Severity:
Summary:
I find no specific mention of interoperability in the DDS 04-04-12 standard proposal. It should be clarified whether the standard is intended to address interoperability, and if so, under what exact conditions (e.g., is it safe to assume that if the DCPS IDL PSM is implemented by IIOP based CORBA ORBs then it will be possible to interoperate?)
RTF Comments: The DDS specification addresses only inter-vendor portability. The specification defines the API and behavior. There is an on-going effort at OMG to address interoperability. In the meantime implementations could be built on top of IIOP. However, given that the DDS Entities are intended to be local communication endpoints and not and not references to the use of IIOP would not be sufficient to achieve interoperability as it IIOP does not address how to represent the QoS, discovery information, and other behaviors necessary to implement DDS. In addition the DDS specification was designed to be implementable on top of connectionless unreliable protocols such as IP multicast and IIOP does not offer direct facilities to do that.
Nature: Enhancement
Summary:
Document 04-04-12 para. 2.2.3 near end
In the implied IDL interface FooTypeSupport for a user type Foo,
there is an operation
DDS::ReturnCode_t register_type(in DDS::DomainParticipant
participant,
in string type_name);
IMHO the type_name argument is superfluous:
The generated stub code can fill it in automatically ("Foo").
RTF Comments: The type name is not superfluous; see section 2.1.2.3.6.1. In some applications, it may be desirable to register the same physical type multiple times (with different participants or the same participant) under different names. However, given that different Topics can already be created that use the same type, and given that typdefs can be used to create new type names. A good argument could be made that there is limited use for the added functionality provided by the type-name parameter. A use case could perhaps be used to clarify the need. As a compromise, the standard could be changed to state that a nil type name is permissible, in which case the default name will be used. Alternatively, the FooTypeSupport class could get an additional method get_type_name() that returns the default type name.
OMG document 04-04-12 para. 2.1.1.2.2 Overall Conceptual Model pg. 2-7 states: At the DCPS level, data types represent information that is sent atomically. For performance reasons, only plain data structures are handled by this level. Please define the term "plain data structures".
* The setting 'autodispose_unregistered_instances = FALSE' causes the
DataWriter [...]
Change FALSE to TRUE.
The table format used for documenting classes contains an "attributes" and an "operations" section. However, in order for applications to be portable across implementations of the DDS spec, it would be desirable to add a "constructors" section that explicitly states those constructors that take one or more arguments (i.e. non-default constructors.)
Filters and Queries are not compile-time checked and are too heavy The 04-04-12 DDS document proposes a subset of SQL for defining filters andqueries. The filter/query expressions are passed into the corresponding methods as type "string". First, this means that conforming implementations need to provide an SQL expression parser/evaluator - a fairly complex piece of software. Second, since the expressions are given as strings, checking them at compile time is not straight-forward. We request the Revision Task Force to reconsider this design decision in favor of less heavyweight approaches that allow for compile-time checks.
RTF Comments: The DDS RTF agrees in principle that it would be a good idea. However we were not able to come up with a suitable proposal that addresses the need for doing the content-filter also at the DataWriter side. Therefore the DDS RTF is recommending this issue is postponed to a future RTF where more implementation experience may be available to suggest the best approach. Resolution: No change to the specification.
The specification contains a number of misspellings and other minor typographical and grammatical errors.
The typographical and grammatical errors shall be corrected.
Revised Text:
Location Original Incorrect Text Corrected Text
2.1.2, fig. 2-4 "Topic Module" "Topic-Definition Module"
2.1.2.2.2 create_participant parameter "domainId" create_participant parameter "domain_id"
2.1.2.2.2 lookup_participant parameter "domainId" lookup_participant parameter "domain_id"
2.1.2.2.2.1 "domainId" "domain_id"
2.1.2.2.2.4 "domainId" (two occurrences) "domain_id" (two occurrences)
2.1.2.3.7, pg. 2-39 "…for a hypothetical application named "Foo"…" "…for a hypothetical application data type named "Foo"…"
2.1.2.4.1.15 "…get_default_datawriter_qos will match the set of valuesspecified on the last successful call to get_default_datawriter_qos…" "…get_default_datawriter_qos will match the set of valuesspecified on the last successful call to set_default_datawriter_qos…"
2.1.2.5, fig. 2-10 SampleInfo attribute "instance_rank" SampleInfo attribute "sample_rank"
2.1.2.5.1, fig. 2-11 transition from NO_WRITERS to ALIVE "…=++" transition from NO_WRITERS to ALIVE "…++"
2.1.2.5.1, pg. 2-57 "time-stamp" "timestamp"
2.1.2.5.1, pg. 2-59, 2nd to last para. "…snapshot of view_state…" "…snapshot of the view_state…"
2.1.2.5.1, pg. 2-61, 4th para. "…multiple DataReader." "…multiple DataReaders."
2.1.2.5.1, pg. 2-61, list item (1) "…list of DataReader…" (two occurrences) "…list of DataReaders…" (two occurrences)
2.1.2.5.1, pg. 2-61 "…acrossDataWriter entities." (two occurrences) "…acrossDataReader entities." (two occurrences)
2.1.2.5.2.7 "…multiple DataReader…" "…multiple DataReaders…"
2.1.3, pg. 2-92 "…ability to: specify and receive coherent changes see the relative order of changes." "…ability to specify and receive coherent changes and to see the relative order of changes."
2.1.3, pg. 2-98 "time-stamp" "timestamp"
2.1.3, pg. 2-101, autopurge_ nowriter_ samples_ delay row "…information regarding instances that have the view_state NOT_ALIVE_NO_WRITERS." "…information regarding instances that have the instance_state NOT_ALIVE_NO_WRITERS."
2.1.3.6 "TIME_BASED_PERIOD" "TIME_BASED_FILTER"
2.1.3.17 last para. "compatible" (two occurrences) "consistent" (two occurrences)
2.1.3.18 last para. "compatible" (two occurrences) "consistent" (two occurrences)
2.1.3.20 itemized list, first bullet "The setting 'autodispose_unregistered_ instances = FALSE' causes the DataWriter…" "The setting 'autodispose_unregistered_ instances = TRUE' causes the DataWriter…"
2.1.3.21, para. 4 "… view_state = NOT_ALIVE_NO_WRITERS…" "… instance_state = NOT_ALIVE_NO_WRITERS…"
2.1.4.1 Requested-Incom-patible-Qos-Status:: total_count row "Total cumulative count the concerned DataReader discovered a DataWriter…" "Total cumulative number of times the concerned DataReader discovered a DataWriter…"
2.1.4.4, before fig. 2-19 Reference to figure 2-18 Reference to figure 2-19
2.1.5 para. 3 "get_datareader" "lookup_datareader"
2.2.3 const long DURATION_INFINITY_SEC = 0x7ffffff;const unsigned long DURATION_INFINITY_NSEC = 0x7ffffff; const long DURATION_INFINITY_SEC = 0x7fffffff;const unsigned long DURATION_INFINITY_NSEC = 0x7fffffff;
2.2.3 interface DomainParticipantFactory { DomainParticipant create_participant( in DomainId_t domainId, in DomainParticipantQos qos, in DomainParticipantListener a_listener); … DomainParticipant lookup_participant( in DomainId_t domainId); … interface DomainParticipantFactory { DomainParticipant create_participant( in DomainId_t domain_id, in DomainParticipantQos qos, in DomainParticipantListener a_listener); … DomainParticipant lookup_participant( in DomainId_t domain_id); …
In a number of instances, there are minor inconsistencies in spelling and naming between the specification's platform-independent model (PIM) and the included IDL platform-specific model (PSM). Resolution: In each case, the most descriptive term of the two options was chosen and the other was conformed to it.
The method DataWriter::register conflicts with the C++ 'register' keyword. Resolution: Replace register and unregister by register_instance and unregister_instance Replace register_w_timestamp and unregister_w_timestamp by register_instance_w_timestamp and unregister_instance_w_timestamp
Since the revisions are straightforward, here only the figures,tables and paragraphs are indicated which are affected by the above indicated change. - update figures 2-8, 2-9, accordingly - update tables in paragraph 2.1.2.4.2 accordingly - update text in paragraphs 2.1.2.4.2.5/6/7/8, 2.1.3.20 and 2.1.3.22.3 accordingly - update IDL in paragraph 2.2.3 accordingly
Summary: In par. 2.1.2.4.2.10 (write) and par. 2.1.2.4.12 (dispose) the specification does not specify an error code in case the specified handle is valid but does not correspond to the given instance (the key value must match), and neither for the case that the specified handle is invalid. Resolution: Specify that in general, the result is unspecified, but that depending on vendor-specific implementations, the resulting error-code is 'PRECONDITION_NOT_MET' if a wrong instance (i.e. with a wrong key-value) is provided and that the resulting error-code is 'BAD_PARAMETER' if a bad handle is provided Revised Text: Add the following text to the end of 2.1.2.4.2.10 (write) In case the provided handle is valid but does not correspond to the given instance, the resulting error-code of the operation will be 'PRECONDITION_NOT_MET'. In case the handle is invalid, the behavior is in general unspecified, but if detectable by a DDS-implementation, the returned error-code will be 'BAD_PARAMETER'. Replace in 2.1.2.4.2.12 (dispose), the text "Possible error codes returned in addition to the standard ones: PRECONDITION_NOT_MET" by the following text: In case the provided handle is valid but does not correspond to the given instance, the resulting error-code of the operation will be 'PRECONDITION_NOT_MET'. In case the handle is invalid, the behavior is in general unspecified, but if detectable by a DDS-implementation, the returned error-code will be 'BAD_PARAMETER'.
In section 2.1.2.5.2.5. (create_datareader) the special value DATAWRITER_QOS_USE_TOPIC_QOS is mistakenly being used instead of DATAREADER_QOS_USE_TOPIC_QOS. Resolution: Replace the wrong text with the correct version. Revised Text: In 2.1.2.5.2.5 (create-datareader) replace the text "The special value DATAWRITER_QOS_USE_TOPIC_QOS" with "The special value "DATAREADER_QOS_USE_TOPIC_QOS
Section 2.1.3. (Supported QoS) the default value of the duration attribute of the READER_DATA_LIFECYCLE QoS is specified as "unlimited".. Resolution: Replace "unlimited" by "infinite", which in general is used in relation with durations. Revised Text: In the QoS-table of paragraph 2.1.3, replace the text "By default, unlimited" as belongs to the READER_DATA_LIFECYCLE QoS by the text "By default, infinite".
The table in section 2.1.3. (Supported QoS) wrongful specifies that USER_DATA concerns Topic. Resolution: 'Topic' should be removed from the 'concerns' column. Revised Text: In the table in section 2.1.3 (Supported QoS), remove from the "USER-DATA" row, and from the "Concerns" column, the word 'Topic'.
In the table in section 2.1.3. (Supported QoS) the DESTINATION_ORDER QoS does not mention the 'datawriter' as concerned entity. Resolution: Add DataWriter to the 'concerns' column. Revised Text: In the table in section 2.1.3 (Supported QoS), add to the "DESTINATION_ORDER" column and the "Concerns" row, the word 'DataWriter'.
In the IDL specification of section 2.2.3, the first parameter of the 'register_type' method is called 'domain' instead of 'participant' (as it is called elsewhere, like in the table of secion 2.1.2.3.6. Resolution: Change the parameter name to 'participant' in the typesupport::register_type IDL. Revised Text: In Chapter 2.2.3 (IDL specification), change the register_type parameter called 'domain' into 'participant'.
In some class diagrams, generic operations are indicated using '_xxx_' in their names instead of fully specifying all the real operations and also some operations are missing. Resolution: - add the missing operations for the dataReader - explicitly mention all operations for the dataReader Revised Text: In the class diagram Fig. 2-8 on page 2-39: - add missing operations "read_w_condition", "take_w_condition" and "return_loan". - rename "read_xxx_w_conditon" into "read_next_w_condition". - rename "take_xxx_w_condition" into "take_next_w_condition"
The class DomainParticipantFactory in figure 2-6 section 2.1.2.2. (Domain Module) misses the operations set_default_participant_qos and get_default_participant_qos.. Resolution: Add the missing operations. Revised Text: In the class diagram Fig. 2-6 of section 2.1.2.2 (Domain Module), add the operations 'set_default_participant_qos' and 'get_default_participant_qos'.
In some of the figures some operations are missing. Resolution: The missing operations shall be added. Revised Text: Location Missing operation 2.1.2.5, fig. 2-10 delete_contained_entities() 2.1.2.2, fig. 2-6 set_default_publisher_qos()get_default_publisher_qos()set_default_subscriber_qos()get_default_subscriber_qos()set_default_topic_qos()get_default_topic_qos()
The specification contains a number of misspellings and other minor typographical and grammatical errors. Resolution: The typographical and grammatical errors shall be corrected. Revised Text: Location Original Incorrect Text Corrected Text 2.1.2.1, fig. 2-5 "Status" (the class name) "Status" 2.1.2.2, fig. 2-6 "domainId" "domain_id"
In the DCPS PSM the Topic class does not specify the methods set_qos, get_qos, set_listener and get_listener.
Resolution:
The methods set_qos, get_qos, set_listener and get_listener shall be added to the IDL description of the Topic class.
Revised Text:
In the IDL in 2.2.3:
interface Topic : Entity, TopicDescription {
…
ReturnCode_t set_qos(
in TopicQos qos);
void get_qos(
inout TopicQos qos);
ReturnCode_t set_listener(
in TopicListener a_listener,
in StatusMask mask);
TopicListener get_listener();
ReturnCode_t get_inconsistent_topic_status(
inout: InconsistentTopicStatus);
…
};
Some of the formal parameter names of ContentFilteredTopic methods are vague. Resolution: The names shall be changed into more distinct names. Revised Text: Location Original incorrect name Corrected name section 2.1.2.2.1, create_contentfilteredtopic expression_parameters filter_parameters section 2.1.2.2.1.7 topic_name related_topic section 2.1.2.2.1.7 expression_parameters filter_parameters section 2.1.2.3.3, get_expression_parameters expression_parameters filter_parameters section 2.1.2.3.3, set_expression_parameters expression_parameters filter_parameters
The last part of the description states: "They both concern Topic, DataWriter and DataReader…"although that furter in the text is described that TOPIC_DATA is only applicable for Topics it would be better to remove this part of the description. Resolution: The last section of paragraph 2.1.3.2 shall be removed. Revised Text: The text: "This QoS is very similar in intent to USER_DATA……primarily on the DataReader/DataWriter." shall be removed.
The description of the Publisher method set_default_datawriter_qos describes the use in case the qos was not explicitly specified at the create_datawriter operation. However, specifying the qos policy at the create_datawriter is not optional, it should state in case the default is used. Resolution: The description shall be modified to clarify the use-case of using the defaults. Revised Text: In section 2.1.2.4.1.15: Replace "in the case where the QoS policies are not explicitly specified" with "in the case where the QoS policies are defaulted
The description of the Entity method set_listener does not describe the result of this method if called with the value of the listener parameter set to NIL. the value NIL is passed for the listener parameter. Chapter 2.1.2.1.1.3 (set_listener): Explicitly state that passing the value NIL for the listener is valid and clears the listener. Resolution: The description of this use-case shall be added to the description. Revised Text: Only one listener can be attached to each Entity. If a listener was already set, the operation set_listener will replace it with the new one. Consequently if the value 'nil' is passed for the listener parameter to this method any existing listener will be removed.
In the class description of the DomainParticipant the description of the attribute domain_id is missing Resolution: The attribute domain_id shall be added to the table in 2.1.2.2.1 The description of attribute domain_id shall be added as section 2.1.2.2.1.26 Revised Text: 1.1.2.2.1.26 domain_id The domain_id identifies the Domain of the DomainParticipant. At creation the DomainParticipant is associated to this domain
The default value of the RELIABILITY qos policy attribute max_blocking_time is not specified. Resolution: The default value shall be specified an arbitrary value greater then zero to avoid that writers will encounter timeouts on acceptable temporary buffer saturations and the value should not be too big since real-time behavior would expect that anything causing writers to block would not sustain for a long time. Revised Text: In section 2.1.3: Add to the description of the RELIABILITY QosPolicy value RELIABLE in the QosPolicy table the text: "The default max_blocking_time=100ms.
It is not clearly defined what should happen when the same condition is attached to the same WaitSet multiple times. Resolution: Explicitly state that this has no effect: subsequent attachments of the same Condition will be ignored. Revised Text: Add a small piece of text to section 2.1.2.1.6.1, which explains that adding a Condition that is already attached to that WaitSet has no effect.
The get_instance method is mentioned in the PIM, but not in the IDL PSM. Resolution: Explicitly state that this is a static method and that it is therefore not specified in IDL. Revised Text: Add a piece of text to section 2.1.2.2.2.3 explaining that the get_instance method is a static method implemented as a native language construction, and can therefore not be expressed in IDL. Add the "static" keyword before the get_instance method mentioned in the table of section 2.1.2.2.2. Add piece of text in section 2.2.2 (right after the introduction of default constructors for WaitSet and GuardCondition) which explains that the DomainParticipantFactory has a static method called get_instance in the native classes that implement it.
It is not clear how the value of a char constant should be expressed in a query expression. Resolution: Clarify that a char constant in a query expression must be places between single quotes. Revised Text: Add a bullet to Appendix B in the section "Token expression" where the char constant is introduced and where is explained how it should be defined (between single quotes, just like the tring). Keep Appendix C inline with this as well
It would be nice to be able to use the "<item>_QOS_DEFAULT" constant in both the set_default_<item>_qos method of its factory and in its set_qos method as well.
Resolution:
Explicitly allow that passing the default qos constant ("<item>_QOS_DEFAULT") to the "set_default_<item>_qos" method in its factory will reset the default qos value for the item to its initial factory default state.
Also state that using the "<item>_QOS_DEFAULT" constant in the set_qos method of an item will change the qos of that item according to the current default of its container entity at the time the call is made.
Revised Text:
For each "set_default_<item>_qos" method in each factory, add the fact that the "<item>_QOS_DEFAULT" constant may be used to revert it back to its factory settings. This impacts sections 2.1.2.2.1.20, 2.1.2.2.1.22, 2.1.2.2.1.24, 2.1.2.4.1.14 and 2.1.2.5.2.15.
For each set_qos method in each entity, state that the corresponding "<item>_QOS_DEFAULT" constant may be used to change the qos of the item according to the current default of its container entity at the time the call is made, provided that this does not change any immutable qos once the entity is enabled. This impacts only section 2.1.2.1.1.1, since the set_qos method explanations are not repeated in the descriptions for every entity specialization.
The get_conditions and wait methods of the WaitSet pass the Conditions in which the user is interested back to the application as out-parameters. This causes unnecessary memory allocations each time a WaitSet is used for that purpose. Resolution: Make the WaitSet result sequence of the inout type for performance reasons, especially because the application is aware of the desired (worst-case) length. The user is then able to recycle these sequences every time. Revised Text: In the table in section 2.1.2.1.6 change the parameter types of the Condition Sequence from out to inout. Explain in sections 2.1.2.1.6.3 and 2.1.2.1.6.4 that the user can either pre-allocate the sequence and force the middleware to overwrite its contents, or to not to pre-allocate and let the middleware allocate the memory for him. Also change the IDL definition for both methods in section 2.2.3.
Appendix B describes an enumeration value as a name::value, during a telephone conference (in a hurry) this is decided to solve ambiguity between attribute names and enumeration labels. The description states that the name specifies the field, that should be the enumeration type. In addition the enumeration type should be a fully specified type name including its scope. This is a lot to specify in a query expression especially because within a query expression the enumeration value is always related to a field that already identifies the type. In addition in SQL enumeration labels are represented as string literals i.e. the values are put between single quotes. Resolution: Treat enumeration values as string literals and place them between single quotes instead of using a scope operator. Revised Text: In Appendix B in the section "Token expression" where the ENUMERATEDVALUE is introduced, replace the sentence that states that "A double colon '::' is used to separate the name of the enumeration from that of the field." with a sentence that states that enumeration labels should be treated as string literals and should therefore be put between single quotes. In the next sentence, remove the part which states that the name of the enumeration should correspond to the name specified in the IDL definition. (But keep the part of the sentence that states that the name of the value should correspond to the names of the labels. Keep Appendix C in line with this as well.
section 2.1.2.1.6.2. (Waitset::detach_condition) describes to return BAD_PARAMETER if the given condition is not attached to the waitset. It would be more appropriate to return PRECONDITION_NOT_MET. Resolution: Change the return-code Revised Text: In section 2.1.2.1.6.2 (Waitset::detach_condition), change all mentioning of BAD_PARAMETER into PRECONDITION_NOT_MET.
DomainParticipants , being entities, can be both enabled or disabled.. Because the DomainParticipantFactory is not an entity and therefore does not have a QoS, it doesn't support a Factory QosPolicy which specifies how to create a DomainParticipant (either enabled or disabled).
Resolution:
Add a DomainParticipantFactoryQos policy to the DomainParticipantFactory, and add the operation set_qos() and get_qos() to the DomainParticipantFactory class. (However, do not make the DomainParticipantFactory an Entity itself!)
Revised Text:
In section 2.1.2.2.2, add the get_qos and set_qos methods to the table. Create two new sections (2.1.2.2.2.7 and 2.1.2.2.2.8), which explain the semantics of these get_qos and set_qos. Also explain that the fact that although the DomainParticipantFactory has a qos, it is not an Entity, since it does not have any StatusConditions or Listeners and cannot be enabled.
Add to the table in section 2.1.3 for the ENTITY_FACTORY policy in the "Concerns" column also the DomainParticipantFactory.
Add to the IDL in section 2.2.3 the following things:
struct DomainParticipantFactoryQos {
EntityFactoryQosPolicy entity_factory;
};
interface DomainParticipantFactory {
…..
ReturnCode_t set_qos(in DomainParticipantQos qos);
ReturnCode_t get_qos(inout DomainParticipantQos qos);
};
The READER_DATA_LIFECYCLE QoS specifies an autopurge_nowriter_samples_delay, however for the same reasons there should also be a autopurge_disposed_samples_delay. Resolution: Add the missing operation Revised Text: In section 2.1.3.21 add at the end: The autopurge_disposed_samples_delay defines the maximum duration for which the DataReader will maintain information regarding an instance once its view_state becomes DISPOSED. After this time elapses, the DataReader will purge all internal information regarding the instance, any untaken samples will also be lost In figure 2-12, class ReaderDataLifecycleQosPolicy, add "autopurge_disposed_samples_delay: Duration_t" In section 2.2.3 (IDL) add the field "Duration_t autopurge_disposed_samples_delay" to struct ReaderDataLifecycleQosPolicy
The mapping from PIM to IDL PSM for the operation Subscriber::get_datareaders represents the PIM 'out' sequence parameter to an IDL 'out' parameter. This maaping is inconsistent with that in other places in the API, in which PIM 'out' parameters are represented as 'inout' in the PSM. An 'out' parameter is also undesirable from a performance perspective. Proposed Resolution: The sequence argument to Subscriber::get_datareaders should be an 'inout' in the IDL PSM. Proposed Revised Text: In section 2.2.3: ReturnCode_t get_datareaders( inout DataReaderSeq readers, in SampleStateMask sample_states, in ViewStateMask v