Data Distribution Service Avatar
  1. OMG Specification

Data Distribution Service — Closed Issues

  • Acronym: DDS
  • Issues Count: 110
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DDS11-125 Page: 2-8 DDS 1.0 DDS 1.1 Resolved closed
DDS11-124 (T#6) Inconsistent name: StatusKindMask DDS 1.0 DDS 1.1 Resolved closed
DDS11-123 R#182) Clarify mapping of PIM 'out' to PSM 'inout' DDS 1.0 DDS 1.1 Resolved closed
DDS11-122 (R#181) Clarify listener and mask behavior with respect to built-in entitie DDS 1.0 DDS 1.1 Resolved closed
DDS11-121 R#180) Clarify which entities appear as instances to built-in readers DDS 1.0 DDS 1.1 Resolved closed
DDS11-120 R#179) Built-in DataReaders should have TRANSIENT_LOCAL durability DDS 1.0 DDS 1.1 Resolved closed
DDS11-119 R#178) Unclear behavior of coherent changes when communication interrupted DDS 1.0 DDS 1.1 Resolved closed
DDS11-118 (R#150) Ambiguous description of create_topic behavior DDS 1.0 DDS 1.1 Resolved closed
DDS11-117 (R#144) Default value for DataWriter RELIABILITY QoS DDS 1.0 DDS 1.1 Resolved closed
DDS11-116 (R#136) Additional operations allowed on disabled entities DDS 1.0 DDS 1.1 Resolved closed
DDS11-115 (R#133) Clarify meaning of LivelinessLost and DeadlineMissed DDS 1.0 DDS 1.1 Resolved closed
DDS11-114 Clarify meaning of LivelinessChangedStatus fields and LIVELINESS le DDS 1.0 DDS 1.1 Resolved closed
DDS11-113 (R#126) Correction to DataWriter blocking behavior DDS 1.0 DDS 1.1 Resolved closed
DDS11-112 (R#117) No way to access Participant and Topic built-in topic data DDS 1.0 DDS 1.1 Resolved closed
DDS11-111 (R#115b) Incorrect description of QoS for built-in readers DDS 1.0 DDS 1.1 Resolved closed
DDS11-110 (R#104) Inconsistent naming of QueryCondition::get_query_arguments DDS 1.0 DDS 1.1 Resolved closed
DDS11-109 O#7966) Confusing terminology: "plain data structures" DDS 1.0 DDS 1.1 Resolved closed
DDS11-108 (T#69) Notification of unsupported QoS policies DDS 1.0 DDS 1.1 Resolved closed
DDS11-107 Read or take next instance, and others with an illegal instance_handle DDS 1.0 DDS 1.1 Resolved closed
DDS11-106 (T#65) Missing get_current_time() function DDS 1.0 DDS 1.1 Resolved closed
DDS11-105 (T#62, R#141) Unspecified TOPIC semantics DDS 1.0 DDS 1.1 Resolved closed
DDS11-104 (T#61) Restrictive Handle definition DDS 1.0 DDS 1.1 Resolved closed
DDS11-103 (T#60) Asynchronous write DDS 1.0 DDS 1.1 Resolved closed
DDS11-102 (T#59) Deletion of disabled entities DDS 1.0 DDS 1.1 Resolved closed
DDS11-101 (T#53) Cannot set listener mask when creating an entity DDS 1.0 DDS 1.1 Resolved closed
DDS11-100 (T#53) Cannot set listener mask when creating an entity DDS 1.0 DDS 1.1 Resolved closed
DDS11-99 (T#51) Identification of the writer of a sample DDS 1.0 DDS 1.1 Resolved closed
DDS11-98 (T#47) Should a topic returned by lookup_topicdescription be deleted DDS 1.0 DDS 1.1 Resolved closed
DDS11-97 (T#46) History when DataWriter is deleted DDS 1.0 DDS 1.1 Resolved closed
DDS11-96 (T#38) request-offered behavior for LATENCY_BUDGET DDS 1.0 DDS 1.1 Resolved closed
DDS11-95 (T#37) Clarification on the value of LENGTH_UNLIMITED constant DDS 1.0 DDS 1.1 Resolved closed
DDS11-94 Clarification of order preservation on reliable data reception DDS 1.0 DDS 1.1 Resolved closed
DDS11-93 (T#23) Syntax of partition strings DDS 1.0 DDS 1.1 Resolved closed
DDS11-92 Inconsistent naming for status parameters in DataReader operations. DDS 1.0 DDS 1.1 Resolved closed
DDS11-91 Behavior of DataReaderListener::on_data_available DDS 1.0 DDS 1.1 Resolved closed
DDS11-90 Remove operations badly put on implied classes DDS 1.0 DDS 1.1 Resolved closed
DDS11-89 Attach_Listener and detach_listener operations on ObjectHome are untyped DDS 1.0 DDS 1.1 Resolved closed
DDS11-88 Parameter wrongly named "object" in implied IDL DDS 1.0 DDS 1.1 Resolved closed
DDS11-87 DlrlOid instead of DLRLOid in implied IDL DDS 1.0 DDS 1.1 Resolved closed
DDS11-86 templateDef explanation contains some mistakes DDS 1.0 DDS 1.1 Resolved closed
DDS11-85 Typo CacheUsage instead of CacheAccess DDS 1.0 DDS 1.1 Resolved closed
DDS11-84 Wrong definition for FooListener DDS 1.0 DDS 1.1 Resolved closed
DDS11-83 ReadOnly exception on clone operations DDS 1.0 DDS 1.1 Resolved closed
DDS11-82 Bad cardinality on figure 3-4 DDS 1.0 DDS 1.1 Resolved closed
DDS11-81 Naming inconsistencies (IDL PSM vs. PIM) for Cache operation DDS 1.0 DDS 1.1 Resolved closed
DDS11-80 Naming inconsistencies (IDL PSM vs. PIM) for ObjectHome operations DDS 1.0 DDS 1.1 Resolved closed
DDS11-79 get_all-topic_names operation missing on figure 3-4 DDS 1.0 DDS 1.1 Resolved closed
DDS11-78 DTD Error (mainTopic DDS 1.0 DDS 1.1 Resolved closed
DDS11-77 (R#154) Undefined behavior if resume_publications is never called DDS 1.0 DDS 1.1 Resolved closed
DDS11-76 (R#153) Ambiguous SampleRejectedStatus::last_reason field DDS 1.0 DDS 1.1 Resolved closed
DDS11-75 (R#152) Extraneous WaitSet::wakeup DDS 1.0 DDS 1.1 Resolved closed
DDS11-74 (R#147) Inconsistent error code list in description of TypeSupport::registe DDS 1.0 DDS 1.1 Resolved closed
DDS11-73 (R#145,146) Inconsistent description of Topic module in PIM DDS 1.0 DDS 1.1 Resolved closed
DDS11-72 (R#142) OWNERSHIP QoS policy should concern DataWriter and DataReader DDS 1.0 DDS 1.1 Resolved closed
DDS11-71 (R#139) Rename *MatchStatus to *MatchedStatus DDS 1.0 DDS 1.1 Resolved closed
DDS11-70 (R#138) Add instance handle to LivelinessChangedStatus DDS 1.0 DDS 1.1 Resolved closed
DDS11-69 (R#135) Add fields to PublicationMatchStatus and SubscriptionMatchStatus DDS 1.0 DDS 1.1 Resolved closed
DDS11-68 Incorrect reference to LIVELINESS_CHANGED in DataWriter::unregister DDS 1.0 DDS 1.1 Resolved closed
DDS11-67 (R#131) Clarify behavior of get_status_changes DDS 1.0 DDS 1.1 Resolved closed
DDS11-66 (R#130) Unspecified behavior of delete_datareader with outstanding loans DDS 1.0 DDS 1.1 Resolved closed
DDS11-65 Unspecified behavior of DataReader/DataWriter creation w/t mismatched Topic DDS 1.0 DDS 1.1 Resolved closed
DDS11-64 (R#127) Improve PSM mapping of BuiltinTopicKey_t DDS 1.0 DDS 1.1 Resolved closed
DDS11-63 (R#125) Additional operations that can return RETCODE_TIMEOUT DDS 1.0 DDS 1.1 Resolved closed
DDS11-62 (R#124) Clarification on the behavior of dispose DDS 1.0 DDS 1.1 Resolved closed
DDS11-61 Need an extra return code: ILLEGAL_OPERATION DDS 1.0 DDS 1.1 Resolved closed
DDS11-60 (R#122) Missing QoS dependencies in table DDS 1.0 DDS 1.1 Resolved closed
DDS11-59 (R#120) Clarify use of DATAREADER_QOS_USE_TOPIC_QOS DDS 1.0 DDS 1.1 Resolved closed
DDS11-58 (R#119) Need lookup_instance method on reader and writer DDS 1.0 DDS 1.1 Resolved closed
DDS11-57 TransportPriority QoS range does not specify high/low priority values DDS 1.0 DDS 1.1 Resolved closed
DDS11-56 R#115) Destination order missing from PublicationBuiltinTopicData DDS 1.0 DDS 1.1 Resolved closed
DDS11-55 R#114) Operations should not return void DDS 1.0 DDS 1.1 Resolved closed
DDS11-54 R#112) Incorrect SampleRejectedStatusKind constants DDS 1.0 DDS 1.1 Resolved closed
DDS11-53 Incorrect field name for USER_DATA, TOPIC_DATA, and GROUP_DATA DDS 1.0 DDS 1.1 Resolved closed
DDS11-52 (R#109) Unused types in IDL DDS 1.0 DDS 1.1 Resolved closed
DDS11-51 (R#107) Missing Topic operations in IDL PSM DDS 1.0 DDS 1.1 Resolved closed
DDS11-50 (R#106b) Parameter passing convention of Subscriber::get_datareaders DDS 1.0 DDS 1.1 Resolved closed
DDS11-49 Add autopurge_disposed_samples_delay to READER_DATA_LIFECYCLE QoS DDS 1.0 DDS 1.1 Resolved closed
DDS11-48 (T#57) Enable status when creating DomainParticipant DDS 1.0 DDS 1.1 Resolved closed
DDS11-47 (T#56) Return values of Waitset::detach_condition DDS 1.0 DDS 1.1 Resolved closed
DDS11-46 (T#55) Modification to how enumeration values are indicated in expressions DDS 1.0 DDS 1.1 Resolved closed
DDS11-45 (T#54) Performance improvement to WaitSet DDS 1.0 DDS 1.1 Resolved closed
DDS11-44 (T#52) Allow to explicitly refer to the default QoS DDS 1.0 DDS 1.1 Resolved closed
DDS11-43 (T#45) Clarification of syntax of char constants within query expressions DDS 1.0 DDS 1.1 Resolved closed
DDS11-42 Explicit mention of static DomainParticipantFactory::get_instance operation DDS 1.0 DDS 1.1 Resolved closed
DDS11-41 (T#42) Behavior when condition is attached to WaitSet multiple times DDS 1.0 DDS 1.1 Resolved closed
DDS11-40 (T#41) Default value for RELIABILITY max_blocking_time DDS 1.0 DDS 1.1 Resolved closed
DDS11-39 Missing description of DomainParticipant::get_domain_id DDS 1.0 DDS 1.1 Resolved closed
DDS11-38 (T#33) Clarification in use of set_listener operation DDS 1.0 DDS 1.1 Resolved closed
DDS11-37 Confusing description of behavior of Publisher::set_default_datawriter_qos DDS 1.0 DDS 1.1 Resolved closed
DDS11-36 (T#30) Ambiguous description of TOPIC_DATA DDS 1.0 DDS 1.1 Resolved closed
DDS11-35 Formal parameter name change in operations of ContentFilteredTopic DDS 1.0 DDS 1.1 Resolved closed
DDS11-34 (T#29) Missing operations to Topic class DDS 1.0 DDS 1.1 Resolved closed
DDS11-33 (T#28) Typographical and grammatical errors DDS 1.0 DDS 1.1 Resolved closed
DDS11-32 T#18,24,) Missing operations and attributes DDS 1.0 DDS 1.1 Resolved closed
DDS11-31 Missing operations on DomainParticipantFactory DDS 1.0 DDS 1.1 Resolved closed
DDS11-30 Spell fully the names for the DataReader operations DDS 1.0 DDS 1.1 Resolved closed
DDS11-29 Formal parameter name improvement in IDL DDS 1.0 DDS 1.1 Resolved closed
DDS11-28 No mention of DESTINATION_ORDER on DataWriterQos DDS 1.0 DDS 1.1 Resolved closed
DDS11-27 Incorrect reference to USER_DATA on TopicQos DDS 1.0 DDS 1.1 Resolved closed
DDS11-26 Default value for READER_DATA_LIFECYCLE DDS 1.0 DDS 1.1 Resolved closed
DDS11-25 Typo in section 2.1.2.5.2.5 DDS 1.0 DDS 1.1 Resolved closed
DDS11-24 (T#4) Typo in section 2.1.2.4.2.10 (write) and section 2.1.2.4.12 (dispose) DDS 1.0 DDS 1.1 Resolved closed
DDS11-23 Operation DataWriter::register DDS 1.0 DDS 1.1 Resolved closed
DDS11-22 Spelling inconsistencies between the PIM and IDL PSM DDS 1.0 DDS 1.1 Resolved closed
DDS11-21 Typographical and grammatical errors DDS 1.0 DDS 1.1 Resolved closed
DDS11-20 DDS 04-04-12 para. 2.1.1.1 Format and conventions DDS 1.0 DDS 1.1 Resolved closed
DDS11-19 2.1.3.20 WRITER_DATA_LIFECYCLE, itemized list, first bullet DDS 1.0 DDS 1.1 Resolved closed
DDS11-18 DDS: DCPS - define the term "plain data structures" DDS 1.0 DDS 1.1 Resolved closed
DDS11-17 DDS: DCPS generated interface FooTypeSupport DDS 1.0 DDS 1.1 Resolved closed
DDS11-16 no specific mention of interoperability in DDS 04-04-12 standard proposal DDS 1.0 DDS 1.1 Resolved closed

Issues Descriptions

Page: 2-8

  • Key: DDS11-125
  • Legacy Issue Number: 8775
  • Status: closed  
  • Source: Vanderbilt University ( Douglas Schmidt)
  • Summary:

    I think the following sentence is incorrect: a Listener is used to provide a callback for synchronous access and a WaitSet associated with one or several Condition objects as far as I can tell, these roles should be reversed. There are a bunch of other bugs in the spec. I'll try to report them as time permits.

  • Reported: DDS 1.0 — Tue, 10 May 2005 04:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#6) Inconsistent name: StatusKindMask

  • Key: DDS11-124
  • Legacy Issue Number: 8582
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In most cases in the specification, when constants of a type named like <something>Kind need to be combined together, a type <something>Mask is defined in the IDL PSM in addition to <something>Kind. The case of StatusKind is inconsistent, however: its mask type is called StatusKindMask, not StatusMask.

    Proposed Resolution:

    Replace StatusKindMask with StatusMask. Clarify the name mapping convention in section 2.2.2.

    Proposed Revised Text:

    Append the following sentence to the fourth paragraph of section 2.2.2: "The name of the mask type is formed by replacing the word 'Kind' with the word 'Mask'."

    Replace "StatusKindMask" with "StatusMask" everywhere it appears in the IDL PSM in section 2.2.3.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#182) Clarify mapping of PIM 'out' to PSM 'inout'

  • Key: DDS11-123
  • Legacy Issue Number: 8581
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    There is already a convention in the specification of mapping an out parameter in the PIM to an inout parameter in the IDL PSM. This convention is useful because it preserves more precise semantics in the PIM while allowing for more performant implementations in language PSMs based on the IDL PSM. However, the convention is never explicitly described in the specification, which could lead to confusion among readers.

    Proposed Resolution:

    The section 2.2.2 PIM to PSM Mapping Rules should explicitly describe and endorse the aforementioned convention.

    Proposed Revised Text:

    Insert a new paragraph after the current first paragraph in section 2.2.2:
    'Out' parameters in the PIM are conventionally mapped to 'inout' parameters in the PSM in order to minimize the memory allocation performed by the Service and allow for more efficient implementations. The intended meaning is that the caller of such an operation should provide an object to serve as a "container" and that the operation will then "fill in" the state of that object appropriately.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#181) Clarify listener and mask behavior with respect to built-in entitie

  • Key: DDS11-122
  • Legacy Issue Number: 8580
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    This issue subsumes two related issues.

    · Presumably, listener callbacks pertaining to built-in entities should fall back to the DomainParticipantListener of their containing DomainParticipant in the usual way in the event that those built-in entities have not requested to receive the callbacks themselves. However, this behavior may prove inconvenient in practice: users-even those completely uninterested in built-in entities-must recognize the callbacks pertaining to those entities and deal with them in some way whenever they install a participant listener. Implementers are also constrained, as they will find it difficult to ensure the correct listener behavior while preserving the freedom to create built-in entities on demand.

    · The specification does not state the behavior of installing a nil listener or what mask values are acceptable in that case.
    Proposed Resolution:

    Installing a nil listener should be equivalent to installing a listener that does nothing. It is acceptable to provide a mask with a nil listener; in that case, no callback will be delivered to the entity or to its containing entities.

    A DomainParticipant's built-in Subscriber and all of its built-in Topics should by default have nil listeners with all mask bits set. Therefore their callbacks will no propagate back to the DomainParticipantListener unless the user explicitly calls set_listener on them.

    Proposed Revised Text:

    Insert a new paragraph after the existing first paragraph of section 2.1.2.1.1.3 set_listener:

    It is permitted to set a nil listener with any listener mask; it is behaviorally equivalent to installing a listener that does nothing.

    Append a new sentence to the final bullet in the list in section 2.1.4.3.1:

    Any statuses appearing in the mask associated with a nil listener will neither be dispatched to the entity itself nor propagated to its containing entities.

    Insert the following paragraph immediately following the table of built-in entity QoS on page 2-129:

    Built-in entities have default listener settings as well. A DomainParticipant's built-in Subscriber and all of its built-in Topics have nil listeners with all statuses appearing in their listener masks. The built-in DataReaders have nil listeners with no statuses in their masks.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#180) Clarify which entities appear as instances to built-in readers

  • Key: DDS11-121
  • Legacy Issue Number: 8579
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification does not explicitly state whether clients of the built-in DataReaders should be able to discover other entities that belong to the same participant by those means. In other words, if a DataReader 'A' belongs (indirectly) to a DomainParticipant 'B', will information about A appear when one reads from the subscription built-in reader of B?

    We believe that most users will not want to "discover" entities they created themselves; the purpose of the built-in entities is to discover what exists elsewhere on the network. Furthermore, there is currently no way for a client of the built-in reader to distinguish between entities belonging to its own DomainParticipant and those that exist elsewhere on the network.

    Proposed Resolution:

    Clarify the descriptions of the built-in topics to indicate that data pertaining to entities of the same participant will not be made available there.

    A mechanism to determine whether an instance handle (read from a built-in topic or obtained through any other means) represents a particular known entity is generally useful. Add the following operations:
    · InstanceHandle_t Entity::get_instance_handle()
    · boolean DomainParticipant::contains_entity(InstanceHandle_t a_handle)

    Proposed Revised Text:

    Add the following sentence to the end of the first paragraph on page 2-129:

    A built-in DataReader object obtained from a given participant will not provide data pertaining to other entities created (directly or indirectly) from that participant under the assumption that such objects are already known to the application.

    Add the following row to the Entity Class table in section 2.1.2.1.1:

    get_instance_handle InstanceHandle_t

    Add the description of the new operation as a new section:

    2.1.2.1.1.8 get_instance_handle

    Get the instance handle that represents the Entity in the built-in topic data, in various statuses, and elsewhere.

    Add the following row to the DomainParticipant Class table in section 2.1.2.2.1:
    contains_entity boolean
    a_handle InstanceHandle_t

    Add the description of the new operation as a new section:

    2.1.2.2.1.26 contains_entity
    This operation checks whether or not the given instance handle represents an entity that was created, directly or indirectly, from the DomainParticipant. The instance handle for an Entity may be obtained from built-in topic data, from various statuses, or from the Entity operation get_instance_handle.

    Add the new operations to the IDL PSM in section 2.2.3:

    interface Entity

    { InstanceHandle_t get_instance_handle(); }

    ;

    interface DomainParticipant : Entity

    { boolean contains_entity(InstanceHandle_t a_handle); }

    ;

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#179) Built-in DataReaders should have TRANSIENT_LOCAL durability

  • Key: DDS11-120
  • Legacy Issue Number: 8578
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The table in 2.1.5 says that built-in DataReaders should have TRANSIENT durability. However, the description of that durability states that support for it is optional.

    Proposed Resolution:

    The specification should be changed to state that built-in readers should have TRANSIENT_LOCAL durability.

    Proposed Revised Text:

    Change TRANSIENT to TRANSIENT_LOCAL in the DURABILITY row of the table on page 2-129.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#178) Unclear behavior of coherent changes when communication interrupted

  • Key: DDS11-119
  • Legacy Issue Number: 8577
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The Publisher entity has operations begin_coherent_changes and end_coherent_changes that allow groups of updates to be received by subscriptions as if they were a single update. Although the specification already contains a general statement about receivers not making updates available until all have been received, no specific mention of communication interruptions or configuration changes is made. This omission has caused questions to be raised with regards to the interactions between coherent changes and partitions, late-joining DataReaders, and network failures.

    Proposed Resolution:

    The specification should be amended to state that a Publisher should not prevent users from changing its partitions while it is in the middle of publishing a set of coherent changes, as the effect of doing so is no different than that of any other connectivity change. However, in the event that connectivity changes occur between the publishers and receivers of data such that some receiver is not able to obtain the entire set, that receiver must act as if it had received none of the data.

    Proposed Revised Text:

    Append the following text to the second paragraph of section 2.1.2.4.1.10 begin_coherent_changes:

    A connectivity change may occur in the middle of a set of coherent changes; for example, the set of partitions used by the Publisher or one of its Subscribers may change, a late-joining DataReader may appear on the network, or a communication failure may occur. In the event that such a change prevents an entity from receiving the entire set of coherent changes, that entity must behave as if it had received none of the set.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#150) Ambiguous description of create_topic behavior

  • Key: DDS11-118
  • Legacy Issue Number: 8576
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The description of the DomainParticipant::create_topic operation in section 2.1.2.2.1.5 states that if an existing topic is found with the same name and QoS, that Topic will be returned; no duplicate Topic will be created. However, the specification fails to describe what will happen in the event that the name and QoS match but the listener is different. Additionally, the behavior places a barrier of understanding before the user, because create_topic behaves differently from all other factory methods in this respect.

    Proposed Resolution:

    Revise the specification to remove the language about reusing Topics. The create_topic operation, like all other 'create' operations in the specification, should always return a new Topic.

    Proposed Revised Text:

    Section 2.1.2.2.1.5 contains the following paragraphs; they should both be stricken from the specification:

    The implementation of create_topic will automatically perform a lookup_topicdescription for the specified topic_name. If a Topic is found, then the QoS and type_name of the found Topic are matched against the ones specified on the create_topic call. If there is an exact match, the existing Topic is returned. If there is no match the operation will fail. The consequence is that the application can never create more than one Topic with the same topic_name per DomainParticipant. Subsequent attempts will either return the existing Topic (i.e., behave like find_topic) or else fail.

    If a Topic is obtained multiple times by means of a create_topic, it must also be deleted that same number of times using delete_topic.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#144) Default value for DataWriter RELIABILITY QoS

  • Key: DDS11-117
  • Legacy Issue Number: 8575
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification states that the default value of the RELIABILITY QoS policy on a DataWriter is BEST_EFFORT; however this makes it automatically incompatible with readers that request a RELIABLE value. This situation is not a problem per se, but it means that applications desiring RELIABLE communications must change the default configuration in two places: both with the reader and with the writer.

    Proposed Resolution:

    Changing the default value-on the DataWriter only-to RELIABLE would make the initial configuration of DDS applications simpler. The default behavior would still be the same because the DataReader would still default to BEST_EFFORT and therefore the default communication would be BEST_EFFORT. However, applications desiring a RELIABLE setting would have to change the defaults in only one place: with the DataReader.

    Proposed Revised Text:

    Append the following sentence to the "Meaning" column of the RELIABILITY RELIABLE row of the table in 2.1.3: "This is the default value for DataWriters."

    The final sentence in the "Meaning" column of the RELIABILITY BEST_EFFORT row of the table in 2.1.3 currently states: "This is the default value." This sentence should be amended: "This is the default value for DataReaders and Topics."

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#136) Additional operations allowed on disabled entities

  • Key: DDS11-116
  • Legacy Issue Number: 8574
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification states that before an entity is enabled, the only operations that can be invoked on it are get/set listener, get/set QoS, get_statuscondition, and factory methods. This list is unnecessarily restrictive.

    Proposed Resolution:

    The following operations should also be allowed:
    · TopicDescription::get_name
    · TopicDescription::get_type_name
    · DomainParticipant::lookup_topicdescription
    · Publisher::lookup_datawriter
    · Subscriber::lookup_datareader
    · Entity::get_status_changes and all get_*_status operations. Note that no status is considered 'triggered' when an Entity is disabled.
    · All get_/set_default_*_qos operations

    Proposed Revised Text:

    Revise the fourth paragraph of section 2.1.2.1.1.7 enable to read:
    If an Entity has not yet been enabled, the following operations may be invoked on it in general:
    · Operations to set or get an Entity's QoS policies (including default QoS policies) and listener
    · get_statuscondition
    · 'factory' operations
    · get_status_changes and other get status operations (although no status of a disabled entity is ever considered changed)
    · 'lookup' operations

    Other operations may explicitly state that they may be called on disabled entities; those that do not will return the error NOT_ENABLED.

    Add the following sentence to sections 2.1.2.3.1.2 (TopicDescription::get_type_name) and 2.1.2.3.1.3 (TopicDescription::get_name): "This operation may be invoked on a Topic that is not yet enabled or on a ContentFilteredTopic or MultiTopic based on such a Topic."

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#133) Clarify meaning of LivelinessLost and DeadlineMissed

  • Key: DDS11-115
  • Legacy Issue Number: 8573
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification does not state whether the LivelinessLostStatus should be considered changed (and the on_liveliness_lost listener callback called) once-when the writer first lost its liveliness-or whether should it be called after every period in which the writer fails to assert its liveliness. For example, if a writer with liveliness set to MANUAL_BY_TOPIC doesn't write for two LIVELINESS lease_duration periods, should the writer listener's on_liveliness_lost callback be called once per lease_duration, or should the callback be called only once after the first lease_duration?

    The analogous ambiguity exists with respect to the *DeadlineMissedStatuses.

    Proposed Resolution:

    The cases are somewhat different in that the deadline is under the application's control while a loss of liveliness is not (e.g. it may occur as a result of a network failure). Therefore, the *DeadlineMissed statuses should be considered changed (and the listeners invoked) at the end of every deadline period. The LivelinessLostStatus, on the other hand, should be considered changed only when a writer's state changes from alive to not alive, not after every lease_duration period thereafter.

    Proposed Revised Text:

    Change the description in the RequestedDeadlineMissed total_count row of the table in 2.1.4.1 (page 2-118) to read: "Total cumulative number of missed deadlines detected for any instance read by the DataReader. Missed deadlines accumulate; that is, each deadline period the total_count will be incremented by one for each instance for which data was not received."

    Change the description in the LivelinessLostStatus total_count row of the table in 2.1.4.1 (page 2-119) to read: "Total cumulative number of times that a previously-alive DataWriter became not alive due to a failure to actively signal its liveliness within its offered liveliness period. This count does not change when an already not alive DataWriter simply remains not alive for another liveliness period."

    Change the description in the OfferedDeadlineMissed total_count row of the table in 2.1.4.1 (page 2-119) to read: "Total cumulative number of offered deadline periods elapsed during which a DataWriter failed to provide data. Missed deadlines accumulate; that is, each deadline period the total_count will be incremented by one."

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify meaning of LivelinessChangedStatus fields and LIVELINESS le

  • Key: DDS11-114
  • Legacy Issue Number: 8572
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    (R#132) Clarify meaning of LivelinessChangedStatus fields and LIVELINESS lease_duration

    Summary:

    The specification of LivelinessChangedStatus doesn't explain what the terms "active" and "inactive" mean nor what change is expected when various events occur. For example, the following actions should be accounted for:
    · Loss of liveliness by a previously alive writer
    · Re-assertion of liveliness on a previously lost writer
    · Normal deletion of an alive writer
    · Normal deletion of a not-alive writer
    · Assertion of liveliness on a new writer
    · A new writer is discovered (i.e. on_publication_match) but its liveliness has not yet been asserted

    The specification is also not clear about the usage of a DataReader's LIVELINESS lease_duration it is not clear whether this field is used solely for QoS compatibility comparison with matching remote writers or if it is also the rate at which the reader will update its LivelinessChangedStatus.

    Proposed Resolution:

    Change "active" to "alive" and "inactive" to "not_alive" in the LivelinessChangedStatus field names.

    In response to the list of events above:
    · Previously alive writer is lost: alive_count_change == -1, not_alive_count_change = 1
    · Lost writer re-asserts liveliness: alive_count_change == 1, not_alive_count_change == -1
    · Normal deletion of alive writer: alive_count_change == -1, not_alive_count_change == 0
    · Normal deletion of not alive writer: alive_count_change == 0, not_alive_count_change == -1
    · New writer asserts liveliness for first time: alive_count_change == 1, not_alive_count_change == 0
    · New writer but hasn't yet asserted liveliness: LivelinessChangedStatus is not changed

    Specify that the information communicated by a reader's LivelinessChangedStatus is out of date by no more than a lease_duration. That is, the reader commits to update its LivelinessChangedStatus if necessary at least once during its lease_duration, although it may update more often if it chooses.

    Proposed Revised Text:

    Add an additional paragraph to the end of section 2.1.3.10 LIVELINESS:

    The information communicated by a DataReader's LivelinessChangedStatus is out of date by no more than a single lease_duration. That is, the reader commits to updating its LivelinessChangedStatus if necessary at least once during each lease_duration, although it is permitted to update more often.

    Change active_count to alive_count, inactive_count to not_alive_count, active_count_change to alive_count_change, and inactive_count_change to not_alive_count_change in figure 2-13 on page 2-117.

    The rows for the LivelinessChangedStatus fields in the table on page 2-118 should be as follows:

    alive_count The total number of currently active DataWriters that write the Topic read by the DataReader. This count increases when a newly matched DataWriter asserts its liveliness for the first time or when a DataWriter previously considered to be not alive reasserts its liveliness. The count decreases when a DataWriter considered alive fails to assert its liveliness and becomes not alive, whether because it was deleted normally or for some other reason.

    not_alive_count The total count of currently DataWriters that write the Topic read by the DataReader that are no longer asserting their liveliness. This count increases when a DataWriter considered alive fails to assert its liveliness and becomes not alive for some reason other than the normal deletion of that DataWriter. It decreases when a previously not alive DataWriter either reasserts its liveliness or is deleted normally.

    alive_count_change The change in the alive_count since the last time the listener was called or the status was read.

    not_alive_count_change The change in the not_alive_count since the last time the listener was called or the status was read.

    Change active_count to alive_count, inactive_count to not_alive_count, active_count_change to alive_count_change, and inactive_count_change to not_alive_count_change in the IDL PSM on page 2-141.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#126) Correction to DataWriter blocking behavior

  • Key: DDS11-113
  • Legacy Issue Number: 8571
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The DDS spec currently states that the max_blocking_time parameter of the RELIABILITY QoS only applies for data writers that are RELIABLE and have HISTORY QoS of KEEP_ALL.

    These assertions are not true. Depending on the RESOURCE_LIMITS QoS, even a KEEP_LAST writer may eventually need to block.

    Proposed Resolution:

    The specification needs to be updated in the table of QoS in Section 2.1.3 and in the DataWriter section 2.1.2.4.2.10 for write to account for the case in which (max_samples < max_instances * HISTORY depth). In this case, the writer may attempt to write a new value for an existing instance whose history is not full and fail because it exceeds the max_samples limit. Therefore, if (max_samples < max_instances * HISTORY depth), then in the situation where the max_samples resource limit is exhausted the middleware is allowed to discard samples of some other instance as long as at least one sample remains for that instance. If it is still not possible to make space available for the new sample, the writer is allowed to block.

    The behavior in the case where max_samples < max_instances must also be described. In that case the writer is allowed to block.

    Proposed Revised Text:

    In the QoS table in 2.1.3, change the first sentence of the "Meaning" cell of the RELIABILITY max_blocking_time row to: "This setting applies only to the case where kind=RELIABLE."

    In section 2.1.2.4.2.10, replace the final paragraph with the following:

    If the RELIABILITY kind is set to RELIABLE, the write operation on the DataWriter may block if the modification would cause data to be lost or else cause one of the limits specified in the RESOURCE_LIMITS to be exceeded. Under these circumstances, the RELIABILITY max_blocking_time configures the maximum time the write operation may block waiting for space to become available. If max_blocking_time elapses before the DataWriter is able to store the modification without exceeding the limits, the write operation will fail and return TIMEOUT.

    Specifically, the DataWriter may block in the following situations (although the list may not be exhaustive), even if its HISTORY kind is KEEP_LAST.

    · If (RESOURCE_LIMITS max_samples < RESOURCE_LIMITS max_instances * HISTORY depth), then in the situation where the max_samples resource limit is exhausted the Service is allowed to discard samples of some other instance as long as at least one sample remains for such an instance. If it is still not possible to make space available to store the modification, the writer is allowed to block.

    · If (RESOURCE_LIMITS max_samples < RESOURCE_LIMITS max_instances), then the DataWriter may block regardless of the HISTORY depth.

    In section 2.1.3.13 RELIABILITY, the second paragraph currently states:

    The setting of this policy has a dependency on the setting of the HISTORY and RESOURCE_LIMITS policies. In case the RELIABILITY kind is set to RELIABLE and the HISTORY kind set to KEEP_ALL the write operation on the DataWriter may block if the modification would cause data to be lost or else cause one of the limits specified in the RESOURCE_LIMITS to be exceeded.

    The above text should be rewritten as follows:

    The setting of this policy has a dependency on the RESOURCE_LIMITS policy. In case the RELIABILITY kind is set to RELIABLE the write operation on the DataWriter may block if the modification would cause data to be lost or else cause one of the limits specified in the RESOURCE_LIMITS to be exceeded.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#117) No way to access Participant and Topic built-in topic data

  • Key: DDS11-112
  • Legacy Issue Number: 8570
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification already provides the operations get_matched_publication_data and get_matched_subscription_data on the DataReader and DataWriter. These operations allow applications to look up information about entities that exist in the domain without having to use the built-in DataReaders directly. It would be useful to have the corresponding ability to look up information about remote DomainParticipants and Topics; however, no such operations exist.

    Proposed Resolution:

    Add the following operations:
    · ReturnCode_t DomainParticipant::get_discovered_participants(inout InstanceHandle_t[] participant_handles)
    · ReturnCode_t DomainParticipant::get_discovered_participant_data(inout ParticipantBuiltinTopicData publication_data, InstanceHandle_t participant_handle)
    · ReturnCode_t DomainParticipant::get_discovered_topics(inout InstanceHandle_t[]topic_handles)
    · ReturnCode_t DomainParticipant::get_discovered_topic_data(inout TopicBuiltinTopicData topic_data, InstanceHandle_t topic_handle)

    Proposed Revised Text:

    Add the names of the aforementioned new operations to figure 2-6.

    Append the following rows to the DomainParticipant Class table in 2.1.2.2.1:

    get_discovered_participant_data ReturnCode_t
    inout: publication_data ParticipantBuiltinTopicData
    participant_handle InstanceHandle

    get_discovered_participants ReturnCode_t
    inout: participant_handles InstanceHandle_t []

    get_discovered_topic_data ReturnCode_t
    inout: topic_data TopicBuiltinTopicData
    topic_handle InstanceHandle

    get_discovered_topics ReturnCode_t
    inout: topic_handles InstanceHandle_t []

    Insert new sections to describe the new operations:

    2.1.2.2.1.26 get_discovered_participant_data

    This operation retrieves information on a DomainParticipant that has been discovered on the network. The participant must be in the same domain as the participant on which this operation is invoked and must not have been "ignored" by means of the DomainParticipant ignore_participant operation.

    The participant_handle must correspond to such a DomainParticipant. Otherwise, the operation will fail and return PRECONDITION_NOT_MET.

    Use the operation get_matched_participants to find the DomainParticipants that are currently discovered.

    The operation may also fail if the infrastructure does not hold the information necessary to fill in the participant_data. In this case the operation will return UNSUPPORTED.

    2.1.2.2.1.27 get_discovered_participants

    This operation retrieves the list of DomainParticipants that have been discovered in the domain and that the application has not indicated should be "ignored" by means of the DomainParticipant ignore_participant operation.

    The operation may fail if the infrastructure does not locally maintain the connectivity information. In this case the operation will return UNSUPPORTED.
    2.1.2.2.1.26 get_discovered_topic_data

    This operation retrieves information on a Topic that has been discovered on the network. The topic must have been created by a participant in the same domain as the participant on which this operation is invoked and must not have been "ignored" by means of the DomainParticipant ignore_topic operation.

    The topic_handle must correspond to such a topic. Otherwise, the operation will fail and return PRECONDITION_NOT_MET.
    Use the operation get_discovered_topics to find the topics that are currently discovered.

    The operation may also fail if the infrastructure does not hold the information necessary to fill in the topic_data. In this case the operation will return UNSUPPORTED.

    2.1.2.2.1.27 get_discovered_topics

    This operation retrieves the list of Topics that have been discovered in the domain and that the application has not indicated should be "ignored" by means of the DomainParticipant ignore_topic operation.
    The operation may fail if the infrastructure does not locally maintain the connectivity information. In this case the operation will return UNSUPPORTED.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#115b) Incorrect description of QoS for built-in readers

  • Key: DDS11-111
  • Legacy Issue Number: 8569
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Summary:

    In Section 2.1.5, there is a table that lists all the QoS policies that are used to create built-in readers. Since the policies are for creating built-in readers, the table should only list the QoS for the corresponding subscriber, reader, and topic. It shouldn't list any policies that occur only in DataWriterQos. Specifically, TRANSPORT_PRIORITY, LIFESPAN, and OWNERSHIP_STRENGTH, all of which apply only to DataWriters, are currently listed erroneously.
    The following QoS are supposed to apply to DataReaders (or their related entities) but are missing from the table: ReaderDataLifecycleQosPolicy, EntityFactoryQosPolicy

    For the QoS that are already listed in the table, some of them don't list the default values of some of the fields.

    DURABILITY: missing service_cleanup_delay value
    RELIABILITY: missing max_blocking_time value

    Proposed Resolution:

    Remove TRANSPORT_PRIORITY, LIFESPAN, and OWNERSHIP_STRENGTH from the table.

    Add the following values:

    READER_DATA_LIFECYCLE autopurge_nowriter_samples_delay = INFINITE
    ENTITY_FACTOR autoenable_created_entities = TRUE
    DURABILITY service_cleanup_delay = 0
    RELIABILITY max_blocking_time = 100 milliseconds

    Proposed Revised Text:
    Change the table in section 2.1.5, page 2-129, as described above.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#104) Inconsistent naming of QueryCondition::get_query_arguments

  • Key: DDS11-110
  • Legacy Issue Number: 8568
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The operations QueryCondition::get_query_arguments and QueryCondition::set_query_arguments are named inconsistently with respect to similar operations on the ContentFilteredTopic and the MultiTopic.

    Proposed Resolution:

    Rename get_query_arguments to get_query_parameters and set_query_arguments to set_query_parameters both in the PIM and PSM.

    Proposed Revised Text:

    Rename get_query_arguments to get_query_parameters and set_query_arguments to set_query_parameters in the table in section 2.1.2.5.9. Rename set_query_arguments to set_query_parameters in the paragraph immediately following the table in the same section.

    Rename get_query_arguments to get_query_parameters in the title of section 2.1.2.5.9.2. Rename set_query_arguments to set_query_parameters within that section (two occurrences).

    Rename set_query_arguments to set_query_parameters in the title to section 2.1.2.5.9.3.

    Rename set_query_arguments to set_query_parameters in figure 2-18.
    Rename get_query_arguments to get_query_parameters and set_query_arguments to set_query_parameters in the IDL PSM in section 2.3.3, page 2-144.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

O#7966) Confusing terminology: "plain data structures"

  • Key: DDS11-109
  • Legacy Issue Number: 8567
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 2.1.1.2.2 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." It is not clear what "plain data structures" means.

    Proposed Resolution:
    Remove the second sentence quoted above from the specification.

    Proposed Revised Text:
    Remove the sentence "For performance reasons, only plain data structures are handled by this level" from section 2.1.1.2.2, page 2-7.

  • Reported: DDS 1.0 — Mon, 14 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#69) Notification of unsupported QoS policies

  • Key: DDS11-108
  • Legacy Issue Number: 8562
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    If a QoS policy is not supported (i.e. is part of an unsupported profile) but the user supplies a non-default value for it, how should the system react
    Resolution:
    Just return UNSUPPORTED
    Revised Text:
    Add a remark in the specification that retcode UNSUPPORTED is returned when supplying a QoS-policy that is not supported by the middleware (i.e. is part of an optional-profile that is not supported by the specific middleware implementation)

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Read or take next instance, and others with an illegal instance_handle

  • Key: DDS11-107
  • Legacy Issue Number: 8561
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Whenever an instance handle is passed as an input-parameter to a dataReader method, it may be invalid e.g. because they are disposed and reclaimed. The semantics of this case should be clarified.
    Resolution:
    Assuming that implementations want to check for invalid handles, they should generically return 'BAD_PARAMETER'.
    Revised Text:
    Specify that BAD_PARAMETER is returned when providing illegal handles to:
    · Read/Take_instance
    · Read/Take_next_instance
    · Read/Take_next_instance_with_condition
    · Get_key_value (both on dataReader and dataWriter)

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#65) Missing get_current_time() function

  • Key: DDS11-106
  • Legacy Issue Number: 8560
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The DDS supports timestamping of information, either automatically or manually. These timestamps also appear in the SampleInfo data. What is missing is a get_current_time() call that allows applications to retrieve the current-time in the format as is utilized by the DDS. This means that the returned format and starting-time is the same as is used by the default/internal DDS timestamping.

    Resolution:
    Add such a 'get_current_time()' function to the participant class
    Revised Text:
    Add and explain the method and update the PSM.

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#62, R#141) Unspecified TOPIC semantics

  • Key: DDS11-105
  • Legacy Issue Number: 8559
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    a) The semantics of the DURABILITY Qos attribute "service_cleanup_delay" in relation to RxO mechanism is not specified.
    b) There is no relation between the history and resource-limits of the durability-service and the history and resource-limits of readers and writers.
    c) the durability-service still has to be configured by means of the above mentioned parameters: 'service_cleanup_delay', 'history' and 'resource-limits'
    Resolution:
    Remove service_cleanup_delay from the DURABILITY QoS policy for readers and writers.
    Add a new QoS "DURABILITY_SETTINGS" on the Topic whose sole purpose is to configure the durability service. The QoS policy should include the parameters: 'service_cleanup_delay', 'history' and 'resource-limits'.
    Revised Text:
    Remove the service_cleanup_delay from the DURABILITY QoS for readers and writers
    Remove the history QoS and resource-limits QoS policies from the TopicBuiltinTopicData
    Add the new DURABILITY_SETTINGS QoS and explain its behavior/meaning.
    Add this QoS policy also to the TopicBuiltinTopicData.
    Update the PSM accordingly

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#61) Restrictive Handle definition

  • Key: DDS11-104
  • Legacy Issue Number: 8558
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The current IDL PSM contains the following lines:

    #define HANDLE_TYPE_NATIVE long
    #define HANDLE_NIL_NATIVE 0

    typedef HANDLE_TYPE_NATIVE InstanceHandle_t;
    const InstanceHandle_t HANDLE_NIL = HANDLE_NIL_NATIVE;

    The two #defines can be vendor-specific. However, the constant definition in the last line restricts the HANDLE_TYPE_NATIVE to be of integer, char, wide_char, boolean, floating_pt, string, wide_string, fixed_pt or octet type; IDL does not allow any other (e.g. structured) types to be assigned a constant value.
    Resolution:
    The PSM contains a number of other elements that cannot be accurately expressed in IDL (e.g. static methods). As in those other cases, a comment should be added stating that structured and other non-primitive types may be used for HANDLE_TYPE_NATIVE and HANDLE_NIL_NATIVE even though IDL can't express it
    Revised Text:
    Mention the above in the introduction of the PSM.

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#60) Asynchronous write

  • Key: DDS11-103
  • Legacy Issue Number: 8557
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Some customers require guarantees on delivery to the network, i.e. a means to block until the service can guarantee that the data will be or is received by all recipients.
    Resolution:
    Add a Publisher::wait_for_acknowlegments(timeout) method that will block until all data written by all its writers has been acknowledged. If called with Publisher is suspended it will return PRECONDITION_NOT_MET
    Revised Text:
    Add a paragraph describing the function, add the function to the publisher-table, change the PSM to include the new function.

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#59) Deletion of disabled entities

  • Key: DDS11-102
  • Legacy Issue Number: 8556
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Currently entities must be enabled before they can be deleted.
    Resolution:
    Specify that entities may be deleted if not enabled.
    Revised Text:
    Explicilty state on each class that the delete method can be called also on disabled entities.

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#53) Cannot set listener mask when creating an entity

  • Key: DDS11-101
  • Legacy Issue Number: 8555
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The entity::set listener method sets a listener in combination with a mask that specifies the event interest. Listeners can also be set at construction of entities by passing the listener as parameter to the entity factory method. However it is not possible to set a mask during construction.
    Resolution:
    Add an event mask parameter (listener_mask) to entity constructors.
    Revised Text:
    Change signature and description of all entity factory methods.

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#53) Cannot set listener mask when creating an entity

  • Key: DDS11-100
  • Legacy Issue Number: 8554
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The entity::set listener method sets a listener in combination with a mask that specifies the event interest. Listeners can also be set at construction of entities by passing the listener as parameter to the entity factory method. However it is not possible to set a mask during construction.
    Resolution:
    Add an event mask parameter (listener_mask) to entity constructors.
    Revised Text:
    Change signature and description of all entity factory methods.

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#51) Identification of the writer of a sample

  • Key: DDS11-99
  • Legacy Issue Number: 8553
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    For applications it is not possible to relate a sample to its datawriter. There are many use cases where it is required to be able to make such a relation
    Resolution:
    Add an 'InstanceHandle_t publication_handle' field (the handle to the remote writer, not the data instance) to SampleInfo. The user can use this handle to call get_matched_publication_data ()
    Revised Text:
    Change SampleInfo definition and related explanation accordingly.

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#47) Should a topic returned by lookup_topicdescription be deleted

  • Key: DDS11-98
  • Legacy Issue Number: 8552
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    It is unclear if a topic found by lookup_topicdescription (section 2.1.2.2.1.13.) should also be deleted if not used anymore similar to find_topic.
    Resolution:
    lookup_topicdescription, unlike find_topic, should search only among the locally created topics. Therefore, it should never (at least as far as the user is concerned) create a new topic description. So looking up the topic should not require any extra deletion. (It is of course permitted to delete a topic one has looked up, provided it has no readers or writers, but then it is really deleted and subsequent lookups will fail).
    Revised Text:
    Change text in section 2.1.2.2.1.13 accordingly

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#46) History when DataWriter is deleted

  • Key: DDS11-97
  • Legacy Issue Number: 8551
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    The specification does not clearly describe what should happen with data in a reliable datawriter's history when the datawriter is deleted? Should it disappear immediately or wait until all messages in the history are delivered?
    Resolution:
    The right thing to do is provide some operation such that the user can wait for all data to be delivered:
    Add an operation Publisher::delete_datawriter_after_acknowledgement( Duration_t timeout). Like DataReader::wait_for_historical_data, this operation takes its own timeout rather than using ReliabilityQosPolicy::max_blocking_time because it has to potentially wait for many writes to complete. As soon as all outstanding reliable samples are acknowledged, the DataWriter will be deleted and the operation will return OK. If timeout expires, however, before all samples are acknowledged, the operation will return TIMEOUT and the writer will not be deleted.
    The regular Publisher::delete_datawriter should delete the writer immediately without waiting for any reliable samples to be acknowlwedged. Its description should be clarified accordingly. If delete_datawriter_after_acknowledgement fails, the user will then have the choice of either calling it again or accepting the possible loss of some samples and calling delete_datawriter.

    Revised Text:
    Change existing text according the resolution.

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#38) request-offered behavior for LATENCY_BUDGET

  • Key: DDS11-96
  • Legacy Issue Number: 8550
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In par. (2.1.3.7) is described that latency budget will neither prohibit connectivity nor send notifications if incompatible. However it also describes the RxO compatibility rule that will never be visible to applications. This is somewhat confusing and this description is only required because this QoS attribute is specified to be subject to the RxO pattern, however, since the description states that the latency budget is a hint to the service and that the service may apply an additional delay for optimizations then are we really speaking of RxO between datawriters and datareaders?
    Resolution:
    Make latency budget truly RxO by making connectivity dependent of compatibility rules and adding appropriate error notifications.
    Revised Text:
    Remove the "therefore the service will not fail to match…" from section 2.1.3.7
    Add new text that describes the RxO consequences

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#37) Clarification on the value of LENGTH_UNLIMITED constant

  • Key: DDS11-95
  • Legacy Issue Number: 8549
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    It is not clear what the value of unlimited resource limits is.
    Resolution:
    Probably it is defined by the in IDL defined constant LENGTH_UNLIMITED=-1. This should be clarified.
    Revised Text:

    Replace "unlimited" with "LENGTH_UNLIMITED" in table in 2.1.3

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification of order preservation on reliable data reception

  • Key: DDS11-94
  • Legacy Issue Number: 8548
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    Does reliability include order preservation up to API level?
    In other words should data be made available to applications if older data exists but has not yet arrived (e.g. due to network irregularities), note that if a late arriving sample is accepted even after newer samples are made available then state inconsistencies may occur. In addition, not accepting a late coming sample should generate a sample lost notification.
    Resolution:
    Specify that data from a single writer (reliable and/or best-effort) will NOT be made available out-of-order.
    Revised Text:
    TBD

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#23) Syntax of partition strings

  • Key: DDS11-93
  • Legacy Issue Number: 8547
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In section 2.1.3 (Supported Qos) the table describes that specifying the PARTITION QOS by an empty sized sequence implies all partitions. However the default partition is specified to be exactly one partition with the name "". Any partition should be specified by means of wildcards. It is unclear how the default partition and wildcards can be used at publisher and subscriber side.
    Resolution:
    Concerning default partitions:
    The default value for PartitionQosPolicy is an empty sequence of names.The empty sequence of partition names is equivalent to a single partition name, the empty string.
    Concerning wildcards:
    "Wildcards" refers to the regular expression language defined by the POSIX fnmatch API (1003.2-1992 section B.6). Either Publisher or Subscriber may include regular expressions in partition names, but no two names that both contain wildcards will ever be considered to match. This means that although regular expressions may be used both at publisher as well as subscriber side, the service will not try to match 2 regular expressions (between publishers and subscribers).
    Revised Text:

    Change the PARTITION row of the table in 2.1.3 to state that the default value is an empty sequence, which is equivalent to a sequence containing the single element "".

    Add the text about the wildcards format and restrictions

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent naming for status parameters in DataReader operations.

  • Key: DDS11-92
  • Legacy Issue Number: 8546
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    In section 2.1.2.1.1.7 it is explained which entity operations may be invoked on an entity that has not yet been enabled. However, in subsequent sections describing the behavior of operations on specialized entities that are disabled, fewer than the above-mentioned operations are mentioned.
    Resolution:
    Add the missing operations for each specialized entity to the list of operations that will never return RETCODE_NOT_ENABLED. Also state explicitly that Conditions obtained from disabled entities will never trigger, until the corresponding entities become enabled.
    Revised Text:
    On page 2-13, section 2.1.2.1.1.7 it is stated that the operation that gets the StatusCondition can be invoked on a disabled entity. Add some text that specifies that a StatusCondition obtained this way will not trigger until the corresponding entity becomes enabled.
    On page 2-21, section 2.1.2.2.1 it is mentioned that for the DomainParticipant all operation except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition, all factory methods (create_topic, create_publisher, create_subscriber) and all delete methods (delete_topic, delete_publisher, delete_subscriber).

    On page 2-35, section 2.1.2.3.2 it is mentioned that for the Topic all operations except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition.
    On page 2-42, section 2.1.2.4.1 it is mentioned that for the Publisher all operations except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition, create_datawriter, delete_datawriter.
    On page 2-48, section 2.1.2.4.2 it is mentioned that for the DataWriter all operations except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition.
    On page 2-63, section 2.1.2.5.2 it is mentioned that for the Subscriber all operations except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition, create_datareader and delete_datareader.
    On page 2-73, section 2.1.2.5.3 it is mentioned that for the DataRaeder all operations except get/set_qos, get/set_listener and enable may return a RETCODE_NOT_ENABLED. To this list should be added: get_statuscondition.

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior of DataReaderListener::on_data_available

  • Key: DDS11-91
  • Legacy Issue Number: 8545
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    It is not clearly defined whether the on_data_available notification should be generated on every arrival of new data, or just on the status change that happens when coming from a no data situation.
    Resolution:
    For every arrival of new data, a notification should be generated, regardless of whether the previous data has already been read before.
    Revised Text:
    Introduce textual changes to 2.1.4.2.2 that describes the complete set of conditions under which the read-communication status will change. The data available status is considered to have changed each time a new sample becomes available or the ViewState, SampleState, or InstanceState of any existing sample changes for any reason other than a read or take.
    Specific changes that cause the status to be changed include:
    · The arrival of new data
    · The disposal of an instance
    · The loss of liveliness of a writer of an instance when no other writer of that instance exists
    · Unregistration of an instance by the last writer of that instance

  • Reported: DDS 1.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove operations badly put on implied classes

  • Key: DDS11-90
  • Legacy Issue Number: 8543
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The "remove" operations of the collection types are mentioned in the implied IDL part, while their signatures have no typed parameters.
    In addition, the parameter for the get operation (key) wrongly starts with a capital letter (while all parameters are supposed to be in small letters)
    Resolution:
    Add those operations on the generic roots and remove them from the generated classes (implied IDL).
    Correct the spelling of the "key" parameter.

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attach_Listener and detach_listener operations on ObjectHome are untyped

  • Key: DDS11-89
  • Legacy Issue Number: 8542
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The ObjectListeners that need to be registered to an ObjectHome are typed (i.e. a FooListener must be attached to a FooHome), but the definition of the attach and detach methods can only be found in the generic IDL part. This way it is possible to attach a BarListener to a FooHome.
    Resolution:
    Move those operations from the generic IDL to the implied one.

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter wrongly named "object" in implied IDL

  • Key: DDS11-88
  • Legacy Issue Number: 8541
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The "set" operation in the implied "FooRef" IDL class has a parameter named object. Since IDL may be used both case-sensitive and case-insensitive, this may not be allowed (possible confusion with CORBA::Object)
    Resolution:
    Name this parameter "an_object"

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DlrlOid instead of DLRLOid in implied IDL

  • Key: DDS11-87
  • Legacy Issue Number: 8540
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In the implied IDL, "DlrlOid" is used 3 times instead of the correct "DLRLOid"
    Resolution:
    Use "DLRLOid" everywhere

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

templateDef explanation contains some mistakes

  • Key: DDS11-86
  • Legacy Issue Number: 8539
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In section 3.2.2.3.2.3, the templateDef is explained. The 2nd bullet presents the possible values of the pattern attribute, but in this list "Ref" is missing. Furthermore, the example uses the wrong attribute name in its 2nd attribute: it says basis="StrMap", while this should be pattern="StrMap"
    Resolution:
    Correct the mistakes.

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo CacheUsage instead of CacheAccess

  • Key: DDS11-85
  • Legacy Issue Number: 8538
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In section 3.1.6.5, the specification suggests that it is sensible to create a CacheUsage per thread. This should say a CacheAccess instead.
    Resolution:
    Change CacheUsage to CacheAccess in the sentence.

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong definition for FooListener

  • Key: DDS11-84
  • Legacy Issue Number: 8537
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    A wrong copy-paste lead to wrong inheritance and methods for the FooListener interface in the implied IDL (while it is correct in the PIM). In addition, the IDL for ObjectListener should have commented out the operation that is actually defined in the derived FooListener.
    FooListener is mentioned once in the PIM as FooObjectListener.
    Resolution:
    Fix the definition (based on ObjectListener) and name the class FooListener everywhere

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReadOnly exception on clone operations

  • Key: DDS11-83
  • Legacy Issue Number: 8536
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The IDL section states that the operations "clone" and "clone_object" on "ObjectRoot" as well as the operation "clone_foo" on the implied IDL for "Foo" may raise the exception "ReadOnlyMode", while this is not true.
    Resolution:
    Correct the IDL

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bad cardinality on figure 3-4

  • Key: DDS11-82
  • Legacy Issue Number: 8535
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Bad cardinality for relations Cache-> CacheListener and ObjectHome->ObjectListener on figure 3-4
    Summary:
    While the PIM text and the IDL state that several CacheListeners may be attached to a Cache and several ObjectListeners may be attached to an ObjectHome, the UML diagram shows a cardinality of at most 1 for those relations
    Resolution:
    Correct the figure to be in accordance with the rest of the document.

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming inconsistencies (IDL PSM vs. PIM) for Cache operation

  • Key: DDS11-81
  • Legacy Issue Number: 8534
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The parameter of "Cache:: find_home_by_index" is named "registration_index" in the PIM and "index" in the IDL
    Resolution:
    Name everywhere that parameter "index"

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming inconsistencies (IDL PSM vs. PIM) for ObjectHome operations

  • Key: DDS11-80
  • Legacy Issue Number: 8533
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The parameter of "ObjectHome::set_filter" operation is named "expression" in the PIM and "filter" in the IDL.
    The ObjectHome operation to register operation is named "register_object" in the UML diagram and in the ObjectHome table, but it is named "register_created_object" in the text and in the IDL.
    Resolution:
    Name everywhere "expression" the parameter of the set_filter" operation
    Name everywhere "register_object" the operation to register an object

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_all-topic_names operation missing on figure 3-4

  • Key: DDS11-79
  • Legacy Issue Number: 8532
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The get_all_topic_names() operation is mentioned in section 3.1.6.3.5 (ObjectHome) and in the IDL, but not in Figure 3-4.
    Resolution:
    Add the missing operation on the UML diagram

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DTD Error (mainTopic

  • Key: DDS11-78
  • Legacy Issue Number: 8531
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The specification states that the mainTopic tag in the classMapping XML element is mandatory. However the example provided after does not contain that item, showing that it is actually not mandatory.
    Resolution:
    Change the status of that item in the DTD, to make it optional.

  • Reported: DDS 1.0 — Thu, 10 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#154) Undefined behavior if resume_publications is never called

  • Key: DDS11-77
  • Legacy Issue Number: 8432
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification fails to state what should happen to publications suspended with Publisher::suspend_publications if Publisher::resume_publications is never called by the time the Publisher is deleted.
    Proposed Resolution:
    The Publisher may be deleted in the situation described. Any samples that have not yet been sent will be discarded.

    Proposed Revised Text:
    Add the following sentence to the last paragraph of section 2.1.2.4.1.8: "If the Publisher is deleted before resume_publications is called, any suspended updates yet to be published will be discarded."

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#153) Ambiguous SampleRejectedStatus::last_reason field

  • Key: DDS11-76
  • Legacy Issue Number: 8431
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The value of the SampleRejectedStatus::last_reason field is undefined in that case where the user calls get_sample_rejected_status when no samples have been rejected.

    Proposed Resolution:
    Introduce a new SampleRejectedStatusKind value NOT_REJECTED and stipulate that it is to be used in the case described above.

    Proposed Revised Text:
    Add the following sentence to the description of SampleRejectedStatus::last_reason in the table on page 2-118: "If no samples have been rejected, the reason is the special value NOT_REJECTED."
    Modify the definition of SampleRejectedStatusKind in 2.2.3 to add a constant NOT_REJECTED.

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#152) Extraneous WaitSet::wakeup

  • Key: DDS11-75
  • Legacy Issue Number: 8430
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The operation WaitSet::wakeup is listed in the UML diagrams in 2.1.2.1 and 2.1.4.4. This operation is not listed in the WaitSet table in 2.1.2.1.6.

    Proposed Resolution:
    The GuardCondition class already provides a mechanism for manually waking up a WaitSet. The wakeup method should be struck from the UML diagrams noted above.

    Proposed Revised Text:
    Remove the wakeup operation from the WaitSet class in figure 2-5 and in figure 2-18.

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#147) Inconsistent error code list in description of TypeSupport::registe

  • Key: DDS11-74
  • Legacy Issue Number: 8429
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The description of register_type in 2.1.2.3.6.1 first says that the operation may return PRECONDITION_NOT_MET but later says that the only "special" error code that may be returned is OUT_OF_RESOURCES.

    Proposed Resolution:
    The operation should be able to return either PRECONDITION_NOT_MET or OUT_OF_RESOURCES.

    Proposed Revised Text:
    The last sentence of section 2.1.2.3.6.1 should read "Possible error codes returned in addition to the standard ones: PRECONDITION_NOT_MET and OUT_OF_RESOURCES."

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#145,146) Inconsistent description of Topic module in PIM

  • Key: DDS11-73
  • Legacy Issue Number: 8428
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Several members in the Topic module are described as attributes in the UML diagram in 2.1.2.3 but as operations in the following tables and in the IDL PSM. These include:
    · TopicDescription::type_name
    · TopicDescription::name
    · ContentFilteredTopic::filter_expression
    · ContentFilteredTopic::expression_parameters
    · MultiTopic::subscription_expression
    · MultiTopic::expression_parameters
    Also, the topic name and type name members are needlessly repeated in the tables of all of the TopicDescription subclasses. They are non-abstract; they need only appear in the TopicDescription table.

    Proposed Resolution:
    The read-only attributes should appear as such in the PIM tables. "Attributes" that can be changed return ReturnCode_t from the corresponding "set" methods; for clarity, they should consistently appear as operations in both the tables and the UML diagram. The duplicate descriptions of the topic name and type name attributes should be removed.
    The IDL PSM should continue to express all of the members as methods to preserve the consistency of the naming conventions used in all programming languages that may be generated from the IDL.

    Proposed Revised Text:

    In figure 2-7, replace the ContentFilteredTopic attribute expression_parameters with two operations: get_expression_parameters and set_expression_parameters. Replace the MultiTopic attribute expression_parameters with two operations: get_expression_parameters and set_expression_parameters.

    Revise the TopicDescription Class table in 2.1.2.3.1 as follows:
    TopicDescription
    attributes
    readonly name string
    readonly type_name string
    operations
    get_participant DomainParticipant

    Rewrite section 2.1.2.3.1.2 as follows:
    2.1.2.3.1.2 type_name
    The type name used to create the TopicDescription.

    Rewrite section 2.1.2.3.1.3 as follows:
    2.1.2.3.1.3 name
    The name used to create the TopicDescription.
    Remove the get_type_name and get_name operations from the Topic Class table in 2.1.2.3.2.
    Remove the get_type_name, get_name, and get_filter_expression operations from the ContentFilteredTopic Class table in 2.1.2.3.3. Add the following attributes to that table:
    attributes
    readonly filter_expression string

    Rewrite section 2.1.2.3.3.2 as follows:
    2.1.2.3.3.2 filter_expression
    The filter_expression associated with the ContentFilteredTopic. That is, the expression specified when the ContentFilteredTopic was created.

    Remove the get_type_name, get_name, and get_subscription_expression operations from the MultiTopic Class table in 2.1.2.3.4. Add the following attributes to that table:
    attributes
    readonly subscription_expression string

    Rewrite section 2.1.2.3.3.2 as follows:
    2.1.2.3.4.1 get_subscription_expression
    The subscription_expression associated with the MultiTopic. That is, the expression specified when the MultiTopic was created.

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#142) OWNERSHIP QoS policy should concern DataWriter and DataReader

  • Key: DDS11-72
  • Legacy Issue Number: 8427
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The OWNERSHIP QoS policy only concerns the Topic Entity. It is the only such policy; all other Topic QoS policies also concern the DataReader and DataWriter, which may override the value provided by the Topic.
    The OWNERSHIP QoS policy is also missing from the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData structures.

    Proposed Resolution:
    The OWNERSHIP QoS policy should concern the Topic, DataReader, and DataWriter Entities. It should have requested vs. offered (RxO) semantics: the two sides must agree on its value.
    A field of type OwnershipQosPolicy should be added to the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData structures.

    Proposed Revised Text:
    Change the "Concerns" column of the OWNERSHIP row of the table on page 2-94 to read "Topic, DataReader, DataWriter."

    The second paragraph of section 2.1.3.8 OWNERSHIP begins "This QoS policy only applies to Topic and not to DataReader or DataWriter…" This paragraph should be removed.

    Add the following rows to the built-in topic table on page 2-131:
    DCPSPublication ownership OwnershipQosPolicy Policy of the corresponding DataWriter
    DCPSSubscription Ownership OwnershipQosPolicy Policy of the corresponding DataReader

    Modify the definitions of the DataWriterQos and DeadReaderQos structures in the IDL PSM in 2.2.3:

    struct DataWriterQos

    { OwnershipQosPolicy ownership; };


    struct DataReaderQosPolicy { OwnershipQosPolicy ownership; }

    ;

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#139) Rename *MatchStatus to *MatchedStatus

  • Key: DDS11-71
  • Legacy Issue Number: 8426
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Most statuses (and the callbacks corresponding to them) have names ending in a past tense verb (e.g. LivelinessLost, LivelinessChanged, *DeadlineMissed, etc.). This convention makes the names very understandable because they refer to an actual thing that happened.
    The publication and subscription match statuses/callbacks violate this convention, however. They are named after the match itself, not the event of matching.

    Proposed Resolution:
    To make the match statuses/callbacks consistent, they should be called PublicationMatchedStatus (on_publication_matched) and SubscriptionMatchedStatus (on_subscription_matched).

    Proposed Revised Text:

    Replace "PublicationMatchStatus" with "PublicationMatchedStatus," "on_publication_match" with "on_publication_matched," "SubscriptionMatchStatus" with "SubscriptionMatchedStatus," and "on_subscription_match" with "on_subscription_matched" in the DomainParticipantListener table in 2.1.2.2.3.

    Perform the same substitutions in the DataWriter table in 2.1.2.4.2 and in the DataWriterListener table in 2.1.2.4.4.

    Perform the same substitutions in the DataReader table in 2.1.2.5.3 and in the DataReaderListener table in 2.1.2.5.7.

    Rename "PublicationMatchStatus" to "PublicationMatchedStatus" and "SubscriptionMatchStatus" to "SubscriptionMatchedStatus" in figure 2-13, in the immediately following table of statuses, and in the IDL PSM definitions of the types PublicationMatchStatus, SubscriptionMatchStatus, DataWriterListener, DataReaderListener, DataWriter, and DataReader.

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#138) Add instance handle to LivelinessChangedStatus

  • Key: DDS11-70
  • Legacy Issue Number: 8425
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    It would be useful to have a field in LivelinessChangedStatus that provides the instance handle for the last DataWriter for which there was a change in liveliness.

    Proposed Resolution:
    Add a field last_publication_handle to LivelinessChangedStatus.

    Proposed Revised Text:
    Add an attribute "last_publication_handle : InstanceHandle_t" to LivelinessChangedStatus in figure 2-13.
    Add a row to the LivelinessChangedStatus section of the table on page 2-118:
    last_publication_handle Handle to the last DataWriter whose change in liveliness caused this status to change.
    Revise the definition of LivelinessChangedStatus in the IDL PSM in 2.2.3:

    struct LivelinessChangedStatus

    { InstanceHandle_t last_publication_handle; }

    ;

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#135) Add fields to PublicationMatchStatus and SubscriptionMatchStatus

  • Key: DDS11-69
  • Legacy Issue Number: 8424
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    There are two limitations to the PublicationMatchStatus and SubscriptionMatchStatus that prevent them from being used to detect the loss of a match:
    · The specification does not indicate whether those statuses are considered to have changed when a match is lost (e.g. as a result of a loss of liveliness or an incompatible QoS change).
    · The status structures contain fields that indicate the total number of matches that have ever occurred, but they lack fields to indicate the number of current matches.

    Proposed Resolution:
    Two fields should be added to each status structure: current_count and current_count_change. The specification should be updated to state that the publication and subscription match statuses are considered to have changed both when a match is established and when it is lost.

    Proposed Revised Text:
    Update the table in 2.1.4.1 as follows:

    DataReader SUBSCRIPTION_MATCH_STATUS The DataReader has found a DataWriter that matches the Topic and has compatible QoS or has stopped communicating with a DataWriter that was previously considered to have matched.

    DataWriter PUBLICATION_MATCH_STATUS The DataWriter has found DataReader that matches the Topic and has compatible QoS or has stopped communicating with a DataReader that was previously considered to have matched.

    Update PublicationMatchStatus and SubscriptionMatchStatus in figure 2-13 to add the following attributes to each:

    current_count : long
    current_count_change : long

    Update the PublicationMatchStatus section of the table on page 2-119 with the following rows:
    current_count The number of DataReaders currently matched to the concerned DataWriter.
    current_count_change The change in current_count since the last time the listener was called or the status was read.

    Update the SubscriptionMatchStatus section of the table on page 2-119 with the following rows:
    current_count The number of DataWriters currently matched to the concerned DataReader.
    current_count_change The change in current_count since the last time the listener was called or the status was read.

    Modify the declarations of the PublicationMatchStatus and SubscriptionMatchStatus structures in the IDL PSM in 2.2.3 as follows:

    struct PublicationMatchStatus

    { long total_count; long total_count_change; long current_count; long current_count_change; InstanceHandle_t last_subscription_handle; }

    ;

    struct SubscriptionMatchStatus

    { long total_count; long total_count_change; long current_count; long current_count_change; InstanceHandle_t last_publication_handle; }

    ;

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect reference to LIVELINESS_CHANGED in DataWriter::unregister

  • Key: DDS11-68
  • Legacy Issue Number: 8423
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    In the description of DataWriter::unregister in section 2.1.2.4.2.7 it says that if an instance is unregistered via a call to DataWriter::unregister, a matched DataReader will get an indication that its LIVELINESS_CHANGED status has changed.
    However, unregister refers to an instance; the LIVELINESS_CHANGED status is based on the liveliness of a DataWriter, not an instance.

    Proposed Resolution:
    Instead the specification should state that the DataReader will receive a sample with a NOT_ALIVE_NO_WRITERS instance state.

    Proposed Revised Text:
    The sentence:
    DataReader objects that are reading the instance will eventually get an indication that their LIVELINESS_CHANGED status (as defined in Section 2.1.4.1) has changed.
    …should be rewritten:
    DataReader objects that are reading the instance will eventually receive a sample with a NOT_ALIVE_NO_WRITERS instance state if no other DataWriter objects are writing the instance.

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#131) Clarify behavior of get_status_changes

  • Key: DDS11-67
  • Legacy Issue Number: 8422
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification does not make clear whether the set of status kinds returned by Entity::get_status_changes when that operation is invoked on a factory Entity (such as a Publisher) should include the changed statuses of the Entities created from that factory (such as a DataWriter).

    Proposed Resolution:
    Clarify that the set of status kinds will only contain the statuses that have changed on the Entity on which get_status_changes is invoked and not that Entity's contained Entities.

    Proposed Revised Text:
    Append the following sentence to section 2.1.2.1.1.6: "A 'triggered' status on an Entity does not imply that that status is triggered on the Entity's factory."

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#130) Unspecified behavior of delete_datareader with outstanding loans

  • Key: DDS11-66
  • Legacy Issue Number: 8421
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification does not state what should occur if the user attempts to delete a DataReader when it has one or more outstanding loans as a result of a call to DataReader::read, DataReader::take, or a variant thereof.

    Proposed Resolution:
    State that Subscriber::delete_datareader should fail and return PRECONDITION_NOT_MET in that case.

    Proposed Revised Text:
    In section 2.1.2.5.2.6 delete_datareader, there is a paragraph (beginning "The deletion of a DataReader is not allowed…") that describes the operation's behavior in the event that some conditions created from the reader have not been deleted. Following that paragraph a new paragraph should be added:
    The deletion of a DataReader is not allowed if it has any outstanding loans as a result of a call to read, take, or one of the variants thereof. If the delete_datareader operation is called on a DataReader with one or more outstanding loans, it will return PRECONDITION_NOT_MET

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified behavior of DataReader/DataWriter creation w/t mismatched Topic

  • Key: DDS11-65
  • Legacy Issue Number: 8420
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification does not currently state whether it is permissible to create a DataReader or DataWriter with a TopicDescription that was created from a DomainParticipant other than that used to create the reader or writer's factory.

    Proposed Resolution:
    The use case in question is not allowed; create_datareader and create_datawriter should return nil in that case.

    Proposed Revised Text:
    The following paragraph should be appended to section 2.1.2.4.1.5 create_datawriter:
    The Topic passed to this operation must have been created from the same DomainParticipant that was used to create this Publisher. If the Topic was created from a different DomainParticipant, this operation will fail and return a nil result.
    The following paragraph should be appended to section 2.1.2.5.2.5 create_datareader:
    The TopicDescription passed to this operation must have been created from the same DomainParticipant that was used to create this Subscriber. If the TopicDescription was created from a different DomainParticipant, this operation will fail and return a nil result.

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#127) Improve PSM mapping of BuiltinTopicKey_t

  • Key: DDS11-64
  • Legacy Issue Number: 8419
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The IDL PSM defines the type BuiltinTopicKey_t to be an array of element type BUILTIN_TOPIC_KEY_TYPE_NATIVE. This definition prevents some compilers from permitting shallow copies of instances of this type.

    Proposed Resolution:
    Redefine BuiltinTopicKey_t to be a structure containing an array rather than the array itself.

    Proposed Revised Text:
    In 2.2.3, change this:

    typedef BUILTIN_TOPIC_KEY_TYPE_NATIVE BuiltinTopicKey_t[3]
    to this:

    struct BuiltinTopicKey_t

    { BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3]; }
  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#125) Additional operations that can return RETCODE_TIMEOUT

  • Key: DDS11-63
  • Legacy Issue Number: 8418
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification currently states that the DataWriter::write operation may return TIMEOUT under certain circumstances. However, the DataWriter operations dispose, register, unregister, and their variants may also block due to a temporarily full history.

    Proposed Resolution:
    Revise the documentation for the listed operations to state that they may return TIMEOUT if the RELIABILITY max_blocking_time elapses.

    Proposed Revised Text:
    The following paragraph should be appended to sections 2.1.2.4.2.5, 2.1.2.4.2.6, 2.1.2.4.2.7, 2.1.2.4.2.8, 2.1.2.4.2.12, and 2.1.2.4.2.13:
    This operation may block if it would cause data to be lost or one of the limits specified in the RESOURCE_LIMITS to be exceeded. Under these circumstances, the RELIABILITY max_blocking_time configures the maximum time this operation may block (waiting for space to become available). If max_blocking_time elapses before the DataWriter is able to store the modification without exceeding the limits, this operation will fail and return TIMEOUT

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#124) Clarification on the behavior of dispose

  • Key: DDS11-62
  • Legacy Issue Number: 8417
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The description of DataWriter::dispose needs to clarify whether it can be called with a nil handle.

    Proposed Resolution:
    DataWriter::dispose should just behave like DataWriter::write in that if the instance is not yet registered, the Service will automatically register it for the user. In that case, the operation should not return PRECONDITION_NOT_MET.

    Proposed Revised Text:
    The second-to-last paragraph in section 2.1.2.4.2.12 states "The operation must be only called on registered instances. Otherwise the operation will return the error PRECONDITION_NOT_MET." This paragraph should be removed.

  • Reported: DDS 1.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need an extra return code: ILLEGAL_OPERATION

  • Key: DDS11-61
  • Legacy Issue Number: 8399
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    It would be useful to have an additional return code called RETCODE_ILLEGAL_OPERATION. This return code would be useful, for example, in preventing the user from performing certain operations on the built-in DataReaders. Their QoS values are stated in the specification; vendors need not allow those values to be changed. Users should also not be allowed to delete built-in Entities. If the user tries to perform either of these two operations, the choices of return code we could use that are in accordance to the spec are:
    · RETCODE_ERROR
    · RETCODE_UNSUPPORTED
    · RETCODE_BAD_PARAMETER
    · RETCODE_PRECONDITION_NOT_MET
    · RETCODE_IMMUTABLE_POLICY

    All of the above fall short of helping the user find out what the problem really is.
    · RETCODE_ERROR: This is the generic error code; it does not give much information as to what might be wrong.
    · RETCODE_UNSUPPORTED: This choice would be semantically incorrect. The failure is not due to a vendor's failure to support an optional feature of the specification, but rather to the user's violation of a policy consistent with the specification that was set by that vendor.
    · RETCODE_BAD_PARAMETER: This return code is a little confusing. For instance, when trying to delete a built-in DataReader, the reader parameter passed is a valid DataReader and the function is expecting a reader. Such usage would seem to constitute passing a good parameter, not a bad one.
    · RETCODE_PRECONDITION_NOT_MET: There is no precondition that the user could change that would make the call work. Therefore, this result would be confusing.
    · RETCODE_IMMUTABLE_POLICY: This return code could potentially work when trying to change the QoS policies of the built-in DataReaders but not when attempting to delete them. However, it would still be semantically incorrect. The problem is not that the user is trying to change immutable QoS policies.

    The QoS policies being changed may be mutable; what is not allowed is the Entity whose policies are in question. Such a return result could lead the user to think that s/he is confused about which QoS policies are mutable.

    Proposed Resolution:
    Add a return code RETCODE_ILLEGAL_OPERATION. This return code indicates a misuse of the API provided by the Service. The user is invoking an operation on an inappropriate Entity or at an inappropriate time. There is no precondition that could be changed to allow the operation to succeed.
    Vendors may use this new return code to indicate violations of policies they have set that are consistent with, but not fully described by, the specification. It is therefore necessary that the return code be considered a "standard" return code (like RETCODE_OK, RETCODE_BAD_PARAMETER, and RETCODE_ERROR) that could potentially be returned by any operation having the return type ReturnCode_t.

    Proposed Revised Text:
    Add the following row to the "Return codes" table in 2.1.1.1:
    ILLEGAL_OPERATION An operation was invoked on an inappropriate object or at an inappropriate time (as determined by policies set by the specification or the Service implementation). There is no precondition that could be changed to make the operation succeed.

    In the paragraph following the table, the sentence "Any operation with return type ReturnCode_t may return OK or ERROR" should be restated "Any operation with return type ReturnCode_t may return OK, ERROR, or ILLEGAL_OPERATION." The sentence "The return codes OK, ERROR, ALREADY_DELETED, UNSUPPORTED, and BAD_PARAMETER are the standard return codes and the specification won't mention them explicitly for each operation" should be restated as "The return codes OK, ERROR, ILLEGAL_OPERATION, ALREADY_DELETED, UNSUPPORTED, and BAD_PARAMETER are the standard return codes and the specification won't mention them explicitly for each operation".

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#122) Missing QoS dependencies in table

  • Key: DDS11-60
  • Legacy Issue Number: 8398
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    A DataReader must specify a TimeBasedFilterQosPolicy::minimum_separation value that is less than or equal to its DeadlineQosPolicy::period value. (Otherwise, all matched DataWriters will be considered to miss every deadline.)
    There are dependencies among the fields of ResourceLimitsQosPolicy: max_samples >= max_samples_per_instance.
    The above dependencies are not made explicit in the specification.

    Proposed Resolution:
    The above dependencies should be made explicit in the QoS policy table in section 2.1.3.

    Proposed Revised Text:
    The following sentence should be added to the "Meaning" column of the "DEADLINE" row: "It is inconsistent for a DataReader to have a deadline period less than its TIME_BASED_FILTER's minimum_separation."

    The following sentence should be added to the "Meaning" column of the "TIME_BASED_FILTER" row: "It is inconsistent for a DataReader to have a minimum_separation longer than its deadline period."

    The following sentence should be added to the "Meaning" column of the "max_samples" row: "It is inconsistent for this value to be less than max_samples_per_instance."

    The following sentence should be added to the "Meaning" column of the "max_samples_per_instance" row: "It is inconsistent for this value to be greater than max_samples."

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#120) Clarify use of DATAREADER_QOS_USE_TOPIC_QOS

  • Key: DDS11-59
  • Legacy Issue Number: 8397
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Title: (R#120) Clarify use of DATAREADER_QOS_USE_TOPIC_QOS constant when creating DataReader on ContentFilteredTopic or MultiTopic

    Summary:
    The specification defines the constant DATAREADER_QOS_USE_TOPIC_QOS that may be used to specify the QoS of a DataReader. The meaning of such usage is unclear when the DataReader's TopicDescription is a ContentFilteredTopic or a MultiTopic since those types do not have QoS of their own.

    Proposed Resolution:
    A ContentFilteredTopic is based on a single Topic; therefore, the meaning of DATAREADER_QOS_USE_TOPIC_QOS is well-defined in that case: it refers to the QoS of the Topic accessible via the ContentFilteredTopic::get_related_topic operation.
    The meaning of DATAREADER_QOS_USE_TOPIC_QOS is not well-defined in the case of a MultiTopic; using it to set the QoS of a DataReader of a MultiTopic is an error. Specifically, passing the constant to Subscriber::create_datareader when a MultiTopic is also passed to that operation will result in the operation returning nil.

    Proposed Revised Text:
    The last paragraph of section "2.1.2.5.2.5 create_datareader" (which begins "The special value…") should be rewritten as follows:
    Provided that the TopicDescription passed to this method is a Topic or a ContentFilteredTopic, the special value DATAREADER_QOS_USE_TOPIC_QOS can be used to indicate that the DataReader should be created with a combination of the default DataReader QoS and the Topic QoS. (In the case of a ContentFilteredTopic, the Topic in question is the ContentFilteredTopic's "related Topic.") The use of this value is equivalent to the application obtaining the default DataReader QoS and the Topic QoS (by means of the operation Topic::get_qos) and then combining these two QoS using the operation copy_from_topic_qos whereby any policy that is set on the Topic QoS "overrides" the corresponding policy on the default QoS. The resulting QoS is then applied to the creation of the DataReader. It is an error to use DATAREADER_QOS_USE_TOPIC_QOS when creating a DataReader with a MultiTopic; this method will return a nil value in that case.

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#119) Need lookup_instance method on reader and writer

  • Key: DDS11-58
  • Legacy Issue Number: 8396
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    There are get_key_value operations in the DataReader and DataWriter to translate from an instance handle to a key. However, in order for a client of the Service to use the per-instance read and take operations of a DataReader, it would be convenient to have an operation to translate in the other direction: from key value(s) to an instance handle.

    Proposed Resolution:
    Add operations DataReader::lookup_instance and DataWriter::lookup_instance.

    Proposed Revised Text:
    Append the following rows to the DataWriter Class table in 2.1.2.4.2:
    lookup_instance InstanceHandle_t
    Instance Data

    Add a new section "2.1.2.4.2.23 lookup_instance" with the following contents:
    This operation takes as a parameter an instance (to get the key value) and returns a handle that can be used in successive operations that accept an instance handle as an argument.
    This operation does not register the instance in question. If the instance has not been previously registered, or if for any other reason the Service is unable to provide an instance handle, the Service will return the special value HANDLE_NIL.

    Append the following rows to the DataReader Class table in 2.1.2.5.3:
    lookup_instance InstanceHandle_t
    Instance Data

    Add a new section "2.1.2.5.3.33 lookup_instance" with the following contents:
    This operation takes as a parameter an instance (to get the key value) and returns a handle that can be used in successive operations that accept an instance handle as an argument.
    If for any reason the Service is unable to provide an instance handle, the Service will return the special value HANDLE_NIL.

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TransportPriority QoS range does not specify high/low priority values

  • Key: DDS11-57
  • Legacy Issue Number: 8395
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification does not state what the valid range of the transport priority values is, now does it state whether higher or lower values correspond to higher priorities.

    Proposed Resolution:
    Stipulate that the range of TransportPriorityQosPolicy::value is the entire range of a 32 bit signed integer. Larger numbers indicate higher priority. However, the precise interpretation of the value chosen is transport- and implementation-dependent.

    Proposed Revised Text:
    The second paragraph of section 2.1.3.14 contains the sentence:
    "As this is specific to each transport it is not possible to define the behavior generically."

    This sentence should be rewritten as follows:
    "Any value within the range of a 32-bit signed integer may be chosen; higher values indicate higher priority. However, any further interpretation of this policy is specific to a particular transport and a particular implementation of the Service. For example, a particular transport is permitted to treat a range of priority values as equivalent to one another."

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#115) Destination order missing from PublicationBuiltinTopicData

  • Key: DDS11-56
  • Legacy Issue Number: 8394
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The PublicationBuiltinTopicData type is missing a destination order field.

    Proposed Resolution:
    Add the missing field in both the PIM and the IDL PSM.

    Proposed Revised Text:
    In the "DCPSPublication" row of the table in 2.1.5, pg. 2-131, add a sub-row like the following after the existing "ownership_strength" sub-row:
    destination_order DestinationOrderQosPolicy Policy of the corresponding DataWriter

    In the IDL PSM, modify the PublicationBuiltinTopicData declaration as follows (the member immediately preceding the new member is show below in order to demonstrate the position of the new member):

    struct PublicationBuiltinTopicData

    { OwnershipStrengthQosPolicy ownership_strength; DestinationOrderQosPolicy destination_order; }

    ;

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#114) Operations should not return void

  • Key: DDS11-55
  • Legacy Issue Number: 8393
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    A number of operations in the specification have a void return type. However, without a specified return type, an implementation cannot indicate that an error occurred.

    Proposed Resolution:
    The following methods currently return void and should return ReturnCode_t instead.
    · GuardCondition::set_trigger_value
    · DomainParticipant::get_default_publisher_qos
    · DomainParticipant::get_default_subscriber_qos
    · DomainParticipant::get_default_topic_qos
    · DomainParticipant::assert_liveliness
    · DomainParticipantFactory::get_default_participant_qos
    · Publisher::get_default_datawriter_qos
    · Subscriber::get_default_subscriber_qos
    · DataWriter::assert_liveliness
    · Subscriber::notify_datareaders
    (The get_qos operations on each concrete Entity type are show to return void in the IDL PSM but a list of QoS policies in the PIM. That inconsistency is addressed in another issue.)

    Proposed Revised Text:
    In the GuardCondition Class table in 2.1.2.1.8, the void return type of set_trigger_value should be replaced by ReturnCode_t. The return type of that operation must be similarly changed in the IDL PSM in 2.2.3.
    In the DomainParticipant Class table in 2.1.2.2.1, the void return type of the get_default_*_qos operations and the assert_liveliness operation should be replaced by ReturnCode_t. The return types of those operations should be similarly changed in the IDL PSM in 2.2.3.
    In the Publisher Class table in 2.1.2.4.1, the void return type of get_default_datawriter_qos should be replaced by ReturnCode_t. The return type of that operation must be similarly changed in the IDL PSM in 2.2.3.
    In the DataWriter Class table in 2.1.2.4.2, the void return type of assert_liveliness should be replaced by ReturnCode_t. The return type of that operation must be similarly changed in the IDL PSM in 2.2.3.
    In the Subscriber Class table in 2.1.2.5.2, the void return type of get_default_datareader_qos and notify_datareaders should be replaced by ReturnCode_t. The return type of those operations must be similarly changed in the IDL PSM in 2.2.3.

  • Reported: DDS 1.0 — Tue, 14 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

R#112) Incorrect SampleRejectedStatusKind constants

  • Key: DDS11-54
  • Legacy Issue Number: 8392
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The constants in the enumeration SampleRejectedStatusKind should correspond to the fields of the RESOURCE_LIMITS QoS policy.

    Proposed Resolution:
    Remove the constant REJECTED_BY_TOPIC_LIMIT. Add the constants REJECTED_BY_SAMPLES_LIMIT and REJECTED_BY_SAMPLES_PER_INSTANCE_LIMIT.

    Proposed Revised Text:
    enum SampleRejectedStatusKind

    { REJECTED_BY_INSTANCE_LIMIT, REJECTED_BY_SAMPLES_LIMIT, REJECTED_BY_SAMPLES_PER_INSTANCE_LIMIT }

    ;

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect field name for USER_DATA, TOPIC_DATA, and GROUP_DATA

  • Key: DDS11-53
  • Legacy Issue Number: 8391
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The QoS table in section 2.1.3 does not mention the field names in the USER_DATA, TOPIC_DATA, and GROUP_DATA QoS policies. The UML diagram in figure 2-12 gives the names of these fields as "data"; however, that name is inconsistent with the names given in the IDL PSM.

    Proposed Resolution:
    The table and figure should indicate that the name of the field in each policy is "value." That name is consistent with the IDL PSM.

    Proposed Revised Text:
    In 2.1.3 figure 2-12, UserDataQosPolicy:
    value [*] : char

    In 2.1.3 figure 2-12, TopicDataQosPolicy:
    value [*] : char

    In 2.1.3 figure 2-12, GroupDataQosPolicy:
    value [*] : char
    In the table in 2.1.3, in the "Value" column of the USER_DATA, TOPIC_DATA, and GROUP_DATA rows:
    "value": a sequence of octets

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#109) Unused types in IDL

  • Key: DDS11-52
  • Legacy Issue Number: 8390
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The types TopicSeq, SampleStateSeq, ViewStateSeq and InstanceStateSeq all appear in the IDL PSM but are never used.

    Proposed Resolution:
    Remove the unused types from the IDL PSM.

    Proposed Revised Text:
    The following declarations should be removed from the IDL PSM:

    typedef sequence<Topic> TopicSeq;
    typedef sequence <SampleStateKind> SampleStateSeq;
    typedef sequence<ViewStateKind> ViewStateSeq;
    typedef sequence<InstanceStateKind> InstanceStateSeq;

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#107) Missing Topic operations in IDL PSM

  • Key: DDS11-51
  • Legacy Issue Number: 8389
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The Topic interface in the PSM is missing the following operations which are present in the PIM: get_qos, set_qos, get_listener, and set_listener.

    Proposed Resolution:
    Add the missing operations to the IDL interface.

    Proposed Revised Text:
    In section 2.2.2:

    interface Topic : Entity, TopicDescription

    { ReturnCode_t get_qos(inout TopicQos qos); ReturnCode_t set_qos(in TopicQos qos); TopicListener get_listener(); ReturnCode_t set_listener( in TopicListener a_listener, StatusKindMask mask); }

    ;

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(R#106b) Parameter passing convention of Subscriber::get_datareaders

  • Key: DDS11-50
  • Legacy Issue Number: 8388
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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 view_states,
    in InstanceStateMask instance_states);

  • Reported: DDS 1.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add autopurge_disposed_samples_delay to READER_DATA_LIFECYCLE QoS

  • Key: DDS11-49
  • Legacy Issue Number: 8384
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#57) Enable status when creating DomainParticipant

  • Key: DDS11-48
  • Legacy Issue Number: 8383
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

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

    ;

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#56) Return values of Waitset::detach_condition

  • Key: DDS11-47
  • Legacy Issue Number: 8382
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#55) Modification to how enumeration values are indicated in expressions

  • Key: DDS11-46
  • Legacy Issue Number: 8381
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#54) Performance improvement to WaitSet

  • Key: DDS11-45
  • Legacy Issue Number: 8380
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#52) Allow to explicitly refer to the default QoS

  • Key: DDS11-44
  • Legacy Issue Number: 8379
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#45) Clarification of syntax of char constants within query expressions

  • Key: DDS11-43
  • Legacy Issue Number: 8378
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Explicit mention of static DomainParticipantFactory::get_instance operation

  • Key: DDS11-42
  • Legacy Issue Number: 8377
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#42) Behavior when condition is attached to WaitSet multiple times

  • Key: DDS11-41
  • Legacy Issue Number: 8376
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#41) Default value for RELIABILITY max_blocking_time

  • Key: DDS11-40
  • Legacy Issue Number: 8375
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing description of DomainParticipant::get_domain_id

  • Key: DDS11-39
  • Legacy Issue Number: 8374
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#33) Clarification in use of set_listener operation

  • Key: DDS11-38
  • Legacy Issue Number: 8373
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Confusing description of behavior of Publisher::set_default_datawriter_qos

  • Key: DDS11-37
  • Legacy Issue Number: 8372
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#30) Ambiguous description of TOPIC_DATA

  • Key: DDS11-36
  • Legacy Issue Number: 8371
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Formal parameter name change in operations of ContentFilteredTopic

  • Key: DDS11-35
  • Legacy Issue Number: 8370
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#29) Missing operations to Topic class

  • Key: DDS11-34
  • Legacy Issue Number: 8369
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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); … }

    ;

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#28) Typographical and grammatical errors

  • Key: DDS11-33
  • Legacy Issue Number: 8368
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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"

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

T#18,24,) Missing operations and attributes

  • Key: DDS11-32
  • Legacy Issue Number: 8367
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing operations on DomainParticipantFactory

  • Key: DDS11-31
  • Legacy Issue Number: 8366
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Spell fully the names for the DataReader operations

  • Key: DDS11-30
  • Legacy Issue Number: 8365
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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"
  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Formal parameter name improvement in IDL

  • Key: DDS11-29
  • Legacy Issue Number: 8364
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No mention of DESTINATION_ORDER on DataWriterQos

  • Key: DDS11-28
  • Legacy Issue Number: 8363
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect reference to USER_DATA on TopicQos

  • Key: DDS11-27
  • Legacy Issue Number: 8362
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Default value for READER_DATA_LIFECYCLE

  • Key: DDS11-26
  • Legacy Issue Number: 8361
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in section 2.1.2.5.2.5

  • Key: DDS11-25
  • Legacy Issue Number: 8360
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(T#4) Typo in section 2.1.2.4.2.10 (write) and section 2.1.2.4.12 (dispose)

  • Key: DDS11-24
  • Legacy Issue Number: 8359
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation DataWriter::register

  • Key: DDS11-23
  • Legacy Issue Number: 8358
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Hans van't Hag)
  • Summary:

    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

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Spelling inconsistencies between the PIM and IDL PSM

  • Key: DDS11-22
  • Legacy Issue Number: 8355
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical and grammatical errors

  • Key: DDS11-21
  • Legacy Issue Number: 8354
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification contains a number of misspellings and other minor typographical and grammatical errors.

  • Reported: DDS 1.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS 04-04-12 para. 2.1.1.1 Format and conventions

  • Key: DDS11-20
  • Legacy Issue Number: 7975
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

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

  • Reported: DDS 1.0 — Tue, 14 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.1.3.20 WRITER_DATA_LIFECYCLE, itemized list, first bullet

  • Key: DDS11-19
  • Legacy Issue Number: 7974
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:
    • The setting 'autodispose_unregistered_instances = FALSE' causes the
      DataWriter [...]

    Change FALSE to TRUE.

  • Reported: DDS 1.0 — Fri, 10 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS: DCPS - define the term "plain data structures"

  • Key: DDS11-18
  • Legacy Issue Number: 7966
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

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

  • Reported: DDS 1.0 — Thu, 2 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DDS: DCPS generated interface FooTypeSupport

  • Key: DDS11-17
  • Legacy Issue Number: 7965
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

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

  • Reported: DDS 1.0 — Thu, 2 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

no specific mention of interoperability in DDS 04-04-12 standard proposal

  • Key: DDS11-16
  • Legacy Issue Number: 7964
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • 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?)

  • Reported: DDS 1.0 — Thu, 2 Dec 2004 05:00 GMT
  • Disposition: Resolved — DDS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT