1. OMG Mailing List
  2. Issues not yet assigned to a Task Force

Unclassified Issues

  • Note: Issues in this list are assigned a temporary issue key (e.g. INBOX-1) which is changed when the issue is assigned to a Task Force. Nevertheless, this temporary issue key will redirect to the new issue key when assigned.
  • Issues Count: 130

Issues Summary

Key Issue Reported Status
INBOX-576 Consider replacing string by String in the diagrams VDML 1.0 pending
INBOX-559 Valuetypes should be added to the list of scopes CORBA 3.3 pending
INBOX-368 merge two references AFP 1.0 pending
INBOX-367 typo to be corrected: External Interface File (EIF)] AFP 1.0 pending
INBOX-327 Typo (missing article) NIEM-UML 3.0 FTF pending
INBOX-175 In section 3.1.6.3.11 regarding the FilterCriterion clarify some things DDS 1.2 pending
INBOX-210 In section 3.1.6.3.5 regarding the CacheListener clarify some things DDS 1.2 pending
INBOX-230 Clarify exceptions for enable_updates and disable_updates operations of Cac DDS 1.2 pending
INBOX-146 Clarify usage of cache_usage operation on the CacheBase, section 3.1.6.3.2 DDS 1.2 pending
INBOX-138 Clarify usage of create_cache operation DDS 1.2 pending
INBOX-119 Proposed Enhancement: allow QoS directly on a DLRL object type? DDS 1.2 pending
INBOX-129 Can a CacheAccess::refresh() throw an AlreadyClonedInWriteMode exception? DDS 1.2 pending
INBOX-126 Request clarification on interface of DLRL object with multi-attribute DDS 1.2 pending
INBOX-125 Request clarification: what can you do with a deleted object? DDS 1.2 pending
INBOX-120 Request clarification of how to handle a dangling related object DDS 1.2 pending
INBOX-130 PIM Spec should have separate tables for Foo types, like DCPS section does DDS 1.2 pending
INBOX-108 Need to clarify what is meant by "RELATED_OBJECTS" DDS 1.1 pending
INBOX-114 create_object and create_unregistered_object DDS 1.2 pending
INBOX-165 Give each CacheAccess its own Publisher and DataWriters DDS 1.2 pending
INBOX-179 section 3.2.2.3.2.13 MultiRelation - XML code DDS 1.2 pending
INBOX-160 Figure 3-4 and section 3.2.1.2.2 Implied IDL DDS 1.2 pending
INBOX-176 section 3.2.2.3.2.13 MultiRelation, 3rd bullet DDS 1.2 pending
INBOX-229 section 3.2.1.2 IDL description on page 3-52 DDS 1.2 pending
INBOX-172 Typos in section 3.1.6.6 DDS 1.2 pending
INBOX-193 Typo in section 3.1.6.1.2.1 DDS 1.2 pending
INBOX-159 Typo in section 3.1.4.2.1 DDS 1.2 pending
INBOX-183 Describe exact behaviour of compositions and associations in the DLRL. DDS 1.2 pending
INBOX-162 objects instances in a writeable CacheAccess DDS 1.2 pending
INBOX-227 Selection should have a non-listener way of obtaining the members DDS 1.2 pending
INBOX-186 The classname in FullOid makes no sense in case of a 'local' Object model DDS 1.2 pending
INBOX-170 Introduce the clear() operation on the Collection interface. DDS 1.2 pending
INBOX-202 Add an attribute to get the home_index DDS 1.2 pending
INBOX-205 Unregistered objects DDS 1.2 pending
INBOX-133 non-existing elements DDS 1.2 pending
INBOX-166 Cache DDS 1.2 pending
INBOX-167 The generated class FooImpl is not mentioned in the implied idl DDS 1.2 pending
INBOX-188 The Implied IDL needs to be extended with attribute examples for class Foo DDS 1.2 pending
INBOX-155 (last) end_updates call on CacheListeners DDS 1.2 pending
INBOX-207 Clarify text on page 3-35 directly following the operation descriptions. DDS 1.2 pending
INBOX-144 Clarify usage of the destroy() operation on the ObjectRoot DDS 1.2 pending
INBOX-226 getter/setter/is_modified operations DDS 1.2 pending
INBOX-147 In section 3.1.6.3.7 regarding the ObjectHome clarify some things DDS 1.2 pending
INBOX-221 Clarify various things with operation enable_all_for_pubsub DDS 1.2 pending
INBOX-163 Clarify exceptions with operation register_all_for_pubsub DDS 1.2 pending
INBOX-178 Unclarities in table in section 3.1.6.2 the row regarding the CacheAccess DDS 1.2 pending
INBOX-121 DLRL Issue: Mismatch between DLRL and CORBA on enumerations DDS 1.2 pending
INBOX-128 DLRL Issue: Error in the IDL for the SelectionListener DDS 1.2 pending
INBOX-118 Should "set" method called outside of writable CacheAccess throw exception? DDS 1.2 pending
INBOX-113 clarify behavior of content_filters in an inheritance hierarchy DDS 1.2 pending
INBOX-111 Specify names of mono-relation and multi-relation fields for default mappin DDS 1.2 pending
INBOX-149 use case for multiple valueFields DDS 1.2 pending
INBOX-174 In section 3.2.3.5 Code example, several typos DDS 1.2 pending
INBOX-208 Various typos in section 3.1.6.3.7, ObjectHome DDS 1.2 pending
INBOX-154 Add an operation to the Cache DDS 1.2 pending
INBOX-204 set_auto_deref, deref_all, underef_all operations DDS 1.2 pending
INBOX-213 Support local class in Mapping XML DDS 1.2 pending
INBOX-161 set_query and set_parameters operation DDS 1.2 pending
INBOX-220 Let the attach/detach listener operation return a boolean DDS 1.2 pending
INBOX-151 Add exceptions, clarify usage of other exceptions DDS 1.2 pending
INBOX-194 Change description on mapping rules for Exceptions or return values DDS 1.2 pending
INBOX-132 Section 3.1.3.1 on page 3-3 DDS 1.2 pending
INBOX-203 Clarify usage of Fully qualified names in the model tags in section 3.2.2.3 DDS 1.2 pending
INBOX-218 Clarify exceptions/usage for remove operation on List in section 3.1.6.3.16 DDS 1.2 pending
INBOX-157 Clarify typical scenario for read mode of a CacheAccess in section 3.1.6.5. DDS 1.2 pending
INBOX-222 Description not detailed enough DDS 1.2 pending
INBOX-173 Clarify usage of the is_modified() operation on the ObjectRoot DDS 1.2 pending
INBOX-190 In section 3.1.6.3.6 regarding the Contract clarify some things DDS 1.2 pending
INBOX-212 Rewrite sentence on page 3-1, section 3.1 DDS 1.2 pending
INBOX-171 Clarify what happens in the purge operation of the CacheAccess DDS 1.2 pending
INBOX-187 Which exceptions can be raised under which circumstances? DDS 1.2 pending
INBOX-198 Clarify usage of refresh operation on the CacheBase, section 3.1.6.3.2 DDS 1.2 pending
INBOX-116 DLRL Issue: Error in the ownership of a SelectionCriterion DDS 1.2 pending
INBOX-117 DLRL Issue: Request clarification on the behavior of is_modified DDS 1.2 pending
INBOX-122 DLRL Issue: Int the future, allow DLRL valuetype implementations? DDS 1.2 pending
INBOX-131 Section: 3.1.4.5 DDS 1.2 pending
INBOX-110 DDS DLRL Issue: Clarify behavior of a Composition DDS 1.2 pending
INBOX-231 A descriptive name DDS 1.2 pending
INBOX-192 Figure 3-4 on page 3-16 is missing some operations in some classes DDS 1.2 pending
INBOX-181 section 3.2.2.3.2.10 MonoAttribute, 3.2.2.3.2.12 MonoRelation DDS 1.2 pending
INBOX-168 In section 3.2.2.3.2.11 MultiAttribute, the example xml code DDS 1.2 pending
INBOX-223 section 3.2.1.2.2 Implied IDL DDS 1.2 pending
INBOX-195 Typos in section 3.2.1.2 IDL description DDS 1.2 pending
INBOX-134 Typos in section 3.1.6.4.1 DDS 1.2 pending
INBOX-217 which_contained_modified operation should be removed DDS 1.2 pending
INBOX-136 Minor typo's and inconsistencies DDS 1.2 pending
INBOX-219 instance_state of a DCPS instance becomes NOT_ALIVE_NO_WRITERS DDS 1.2 pending
INBOX-145 Indicate the semantics of merging separate topics into one single object DDS 1.2 pending
INBOX-184 DLRL object DDS 1.2 pending
INBOX-153 How are deleted objects treated in a CacheBase and a Selection DDS 1.2 pending
INBOX-189 FilterCriterion DDS 1.2 pending
INBOX-201 Proposal to make the is_xxx_modified operation optional DDS 1.2 pending
INBOX-215 Prevent writing contents of CacheAccess while 'invalid' relations exists DDS 1.2 pending
INBOX-214 getters of relationships DDS 1.2 pending
INBOX-169 Add attribute to CacheAccess (section 3.1.6.3.3) DDS 1.2 pending
INBOX-228 DCPSError also becomes a 'runtime' exception DDS 1.2 pending
INBOX-150 Describe exact event propagation in case of inheritance + multiple listener DDS 1.2 pending
INBOX-200 Clearly separate default mapping from pre-defined mapping DDS 1.2 pending
INBOX-197 The read_state of a cache object contains some typos DDS 1.2 pending
INBOX-196 Section 3.2.1.2.1 Generic DLRL Entities get_instance DDS 1.2 pending
INBOX-225 Clarify listeners DDS 1.2 pending
INBOX-142 Clarify exceptions DDS 1.2 pending
INBOX-137 Clarify usage of find_home_by_name DDS 1.2 pending
INBOX-139 Clarify exception condition DDS 1.2 pending
INBOX-209 Unclarities in section 3.1.4.2.3 DDS 1.2 pending
INBOX-115 IDL interfaces for ObjectListener and FooListener are inconsistent DDS 1.2 pending
INBOX-127 DLRL Issue: Need clarification on limitations of bi-directional association DDS 1.2 pending
INBOX-123 Request clarification on a WRITE_ONLY CacheAccess, cloning, and refresh() DDS 1.2 pending
INBOX-124 DLRL Issue: Diagrams in Fig 3.5 and Fig 3.6 look improperly captioned DDS 1.2 pending
INBOX-112 DDS DLRL Issue: Clarification on the use of a Set in a DLRL Query DDS 1.2 pending
INBOX-140 Inconsistency in attribute definitions for valuetype ObjectRoot DDS 1.2 pending
INBOX-152 Section 3.2.1.1 Mapping Rules regarding error reporting DDS 1.2 pending
INBOX-216 In section 3.2.2.3.2.11 MultiAttribute. DDS 1.2 pending
INBOX-182 Typos in section 3.2.1.2 IDL description DDS 1.2 pending
INBOX-135 Typos in section 3.1.6.4.3 & 3.1.6.4.4 DDS 1.2 pending
INBOX-211 Various typos in section 3.1.6.3.4, Cache DDS 1.2 pending
INBOX-185 cloned objects DDS 1.2 pending
INBOX-141 Extend the XML to allow optional relationships DDS 1.2 pending
INBOX-156 There is a lot of redundancy in the XML file. DDS 1.2 pending
INBOX-143 Cache should have a getter to obtain its related DomainParticipant. DDS 1.2 pending
INBOX-199 Enable_all_for_pubsub operation DDS 1.2 pending
INBOX-191 Relationships to objects that have been deleted are not allowed. DDS 1.2 pending
INBOX-164 Remove the CacheDescription object DDS 1.2 pending
INBOX-180 samples from the underlying DataReaders DDS 1.2 pending
INBOX-206 Unclear sentence in section 3.1.6.1.1 DDS 1.2 pending
INBOX-148 Usage of Undefined unclear DDS 1.2 pending
INBOX-177 Clarify what happens with selection->refresh if auto_refresh is true DDS 1.2 pending
INBOX-158 Clarify typical scenario for write mode of CacheAccess in section 3.1.6.5.2 DDS 1.2 pending
INBOX-224 Clarify exceptions for add/put operations on List in section 3.1.6.3.16 DDS 1.2 pending
INBOX-109 clarify allowable (spec compliant) ways to implement ObjectReference[]. DDS 1.1 pending
INBOX-73 Thing UML 2.5 pending

Issues Descriptions

Consider replacing string by String in the diagrams

  • Key: INBOX-576
  • Status: pending  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    In the VDML 1.0 specification, the definition text in the specification assumes the UML predefined type “String” (with capital “S”), however, the meta-model diagrams expose the type “string” (lower case “s”). This means that the meta-model (and so the XMI) actually use the type “string”. This has several problems. Firstly, it is not a predefined UML type, and the VDML specification neither defines it, so, it is basically undefined. Secondly, SMM 1.1 is integrated into VDML 1.0, and SMM 1.1 uses the predefined UML type “String” (with capital “S”). Hence VDML has better also use the UML type “String”.

  • Reported: VDML 1.0 — Mon, 20 Nov 2017 13:19 GMT
  • Updated: Mon, 20 Nov 2017 13:19 GMT
  • Attachments:

Valuetypes should be added to the list of scopes

  • Key: INBOX-559
  • Status: pending  
  • Source: Self ( Jonathan Biggar)
  • Summary:

    In this section, there are two places where the list of IDL constructs that have scopes is given:

    "interface, struct, union, or exception"

    valuetype should be added to this list to be consistent with the rest of the specification.

  • Reported: CORBA 3.3 — Wed, 18 Oct 2017 23:48 GMT
  • Updated: Tue, 31 Oct 2017 14:00 GMT
  • Attachments:

merge two references

  • Key: INBOX-368
  • Status: pending  
  • Source: Allasia ( Walter)
  • Summary:

    Definition of External Input:
    Consider to merge (ISO). (ISO/IEC 20926:2009) into just the last one: "(ISO/IEC 20926:2009)"

  • Reported: AFP 1.0 — Thu, 15 Dec 2016 15:05 GMT
  • Updated: Mon, 25 Sep 2017 14:39 GMT
  • Attachments:

typo to be corrected: External Interface File (EIF)]

  • Key: INBOX-367
  • Status: pending  
  • Source: Allasia ( Walter)
  • Summary:

    Bracket "]" at the end to be removed
    Definition of EIF: External Interface File (EIF)]

  • Reported: AFP 1.0 — Thu, 15 Dec 2016 15:04 GMT
  • Updated: Mon, 25 Sep 2017 14:38 GMT
  • Attachments:

Typo (missing article)

  • Key: INBOX-327
  • Status: pending  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Sentence 2: Change: "is very common task" to "is a very common task".

  • Reported: NIEM-UML 3.0 FTF — Mon, 26 Sep 2016 19:16 GMT
  • Updated: Mon, 25 Sep 2017 14:37 GMT
  • Attachments:

In section 3.1.6.3.11 regarding the FilterCriterion clarify some things

  • Key: INBOX-175
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In the description for the check_object method is should state that the membership_state is optional in the sense that implementations of the spec may or may not use this parameter. If not used it always states an UNDEFINED_MEMBERSHIP state.

    Solution:

    Replace:
    o check if an object passes the filter - return value is TRUE - or not - return value is FALSE (check_object). This method is called with the first parameter set to the object to be checked and the second parameter set to indicate whether the object previously passed the filter (membership_state). The second parameter (which is actually an enumeration with three possible values - UNDEFINED_MEMBERSHIP, ALREADY_MEMBER and NOT_MEMBER) is useful when the FilterCriterion is attached to a Selection to allow writing optimized filters.
    With:
    o check if an object passes the filter - return value is TRUE - or not - return value is FALSE (check_object). This method is called with the first parameter set to the object to be checked and the second parameter set to indicate whether the object previously passed the filter (membership_state). The second parameter (which is actually an enumeration with three possible values - UNDEFINED_MEMBERSHIP, ALREADY_MEMBER and NOT_MEMBER) is optional and may be useful when the FilterCriterion is attached to a Selection to allow writing optimized filters. The membership_state parameter has a default value of UNDEFINED_MEMBERSHIP in case the implementation does not support this option.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

In section 3.1.6.3.5 regarding the CacheListener clarify some things

  • Key: INBOX-210
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem (1/3):
    In the description for the on_begin_updates it says at the end '(assuming that updates_enabled is true)', which is a bit vague as to the context of that statement. Replace it with something like "This operation will only be triggered for a Cache which has updates_enabled set to true." That statement should also be added at the end of the on_end_updates operation.
    This clarification is required because the other two operations are not dependant on the state of the updates_enabled…

    Solution (1/3):
    Replace:
    o on_begin_updates indicates that updates are following. Actual modifications in the cache will be performed only when exiting this method (assuming that updates_enabled is true).
    o on_end_updates indicates that no more update is foreseen.

    With:
    o on_begin_updates indicates that updates are following. Actual modifications in the Cache will be performed only when exiting this method. This operation will only be triggered for a Cache which has updates_enabled set to true.
    o on_end_updates indicates that no more update is foreseen. This operation will only be triggered for a Cache which has updates_enabled set to true.

    Problem (2/3):
    The paragraph following the descriptions for all operations says: "In between, the updates ….". Since two new operations where added in the last spec revision this statement is now unclear. In between which operations? This should be clarified to state in between the on_begin_updates and on_end_updates.

    Solution (2/3):
    Replace:
    In between, the updates are reported on home or selection listeners. Section 3.1.6.4, "Listeners Activation," on page 3-41 describes which notifications are performed and in what order.
    With:
    In between the on_begin_updates and the on_end_updates calls the updates are reported on home or selection listeners. Section 3.1.6.4, "Listeners Activation," on page 3-41 describes which notifications are performed and in what order.

    Problem (3/3):
    The description for the on_updates_enabled and on_updates_disabled both start with a wrong quotation mark. It should be removed.

    Solution (3/3):
    Replace:
    o "on_updates_enabled - indicates that the Cache has switched to automatic update mode. Incoming data will now trigger the corresponding Listeners.
    o "on_updates_disabled - indicates that the Cache has switched to manual update mode. Incoming data will no longer trigger the corresponding Listeners, and will only be taken into account during the next refresh operation.
    With:
    o on_updates_enabled - indicates that the Cache has switched to automatic update mode. Incoming data will now trigger the corresponding Listeners.
    o on_updates_disabled - indicates that the Cache has switched to manual update mode. Incoming data will no longer trigger the corresponding Listeners, and will only be taken into account during the next refresh operation.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exceptions for enable_updates and disable_updates operations of Cac

  • Key: INBOX-230
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.3.4 on page 3-23 for the descriptions of the enable and disable updates operation it should state a PreconditionNotMet is thrown if the cache is created with a usage of WRITE_ONLY. It should also state that multiple calls to the operations is considered a no-op. It should also be stated that calling the disable_updates operation results in all cache listeners being triggered with the on_updates_disabled call and for the enable the on_updates_enabled is called in scope of the thread making the call to enable or disable updates.

    Solution:

    Replace (see issue XXX(PT-DLRL-TYPO-0011) which already made changes to the disable_updates description):
    o disable_updates causes incoming but not yet applied updates to be registered for further application, any update round in progress will be completed before the disable updates instruction is taken into account.

    o enable_updates causes the registered (and thus not applied) updates to be takeninto account, and thus to trigger the attached Listener, if any.

    With:
    o disable_updates causes incoming but not yet applied updates to be registered for further application, any update round in progress will be completed before the disable updates instruction is taken into account. All registered CacheListeners will be triggered with the on_updates_disabled call (in scope of the thread calling the disable_updates operation) signaling, to any interested party, that updates on the Cache will no longer be automatically processed and no longer result in listener triggers. If the cache_usage of the Cache is WRITE_ONLY then a PreconditionNotMet is raised.

    o enable_updates causes the registered (and thus not applied) updates to be taken into account, and thus to trigger the attached CacheListeners, if any. All registered CacheListeners will be triggered before any updates are applied with the on_updates_enabled call (in scope of the thread calling the enabled_updates operation) signaling, to any interested party, that the updates on the Cache will be automatically processed and thus result in listener triggers. If the cache_usage of the Cache is WRITE_ONLY then a PreconditionNotMet is raised.

    In the IDL description in section 3.2.1.2 on page 3-58 replace:
    // — Updates management
    void enable_updates ();
    void disable_updates ();
    With:
    // — Updates management
    void enable_updates () raises (PreconditionNotMet);
    void disable_updates ()raises (PreconditionNotMet);;

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of cache_usage operation on the CacheBase, section 3.1.6.3.2

  • Key: INBOX-146
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The explanation of the cache usage only talks about the intent to support write operations. However if the usage is WRITE_ONLY there is no intent to support read operations, such as refresh as well. This should be stated as such.

    Solution:

    Replace:
    The cache_usage indicates whether the cache is intended to support write operations (WRITE_ONLY or READ_WRITE) or not (READ_ONLY). This attribute is given at creation time and cannot be changed afterwards.

    With:
    The cache_usage indicates whether the cache is intended to support write operations only (WRITE_ONLY) or read operation only (READ_ONLY) or both read and write operation (READ_WRITE). This attribute is given at creation time and cannot be changed afterwards.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of create_cache operation

  • Key: INBOX-138
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The create_cache operation is responsible for creating a DCPS publisher and/or subscriber, depending on the cache usage. If this creation fails a DCPSerror should be thrown, the text should state this.
    It should also be stated that a cache is created by default with updated_enabled() returning false, forcing the application to explicitly enable the cache for updates. This prevents that the application immediately starts receiving updates after the enable_all_for_pubsub.

    It should also be clarified that the QoS settings on the participant determine if the publisher/subscriber will be created as enabled or disabled entities. IE if the QoS setting for autoenable_created_entities is set to true on the partcipant the Subscriber and Publisher are created in an enabled state, if set to false then both entities will be created in a disabled state.

    Solution:
    Replace:
    Depending on the cache_usage a Publisher, a Subscriber, or both will be created for the unique usage of the Cache. These two objects will be attached to the passed DomainParticipant.

    With:
    Depending on the cache_usage a Publisher, a Subscriber, or both will be created for the unique usage of the Cache. These two objects will be attached to the passed DomainParticipant. If the creation of the Publisher and/or Subscriber required by the Cache fails a DCPSError is raised. The Cache is created with updates disabled by default (updates_enabled() returning false). The autoenable_created_entities QoS setting of the entity_factory of the passed DomainParticipant determines if the Publisher and/or Subscriber will be created in an enabled or a disabled state. If this QoS setting is set to true then these entities will be created in an enabled state, if set to false then these entities will be created in a disabled state. The Publisher and/or Subscriber themselves will always have their entity_factory.autoenable_created_entities QoS setting set to false, ensuring that DataWriter and DataReader entities are created in a disabled state, this setting may be overridden before the register_all_for_pubsub() call to the created Cache, which will result in the DataWriter and DataReader entities to be created as enabled entities, in this scenario updates will be received from the moment the register_all_for_pubsub is called, but can only be viewed after a call to the enable_all_for_pubsub.
    The creation of Topic entities during the register_all_for_pubsub is also slaved to the passed DomainParticipant's entity_factory.autoenable_created_entities QoS setting at the time the register_all_for_pubsub() is called.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Proposed Enhancement: allow QoS directly on a DLRL object type?

  • Key: INBOX-119
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    It might be useful to allow QoS settings directly on a DLRL object type. For things like HISTORY, it would be a lot cleaner to apply QoS at the DLRL object type level (say, an object type and everything related to a certain depth) and let DLRL pass it through to DCPS.
    That way, the user doesn't need to know his application's DLRL-to-DCPS mapping – the same QoS application code could be used regardless of how the DLRL-to-DCPS mapping is configured. The user's QoS code wouldn't depend on the details of the application's mapping, which could change.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Can a CacheAccess::refresh() throw an AlreadyClonedInWriteMode exception?

  • Key: INBOX-129
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    Can a CacheAccess::refresh() throw an AlreadyClonedInWriteMode exception?

    Suppose an object is cloned into a writable CacheAccess with scope=RELATED_OBJECTS and some depth >1. Now, suppose object2, which is unrelated, is cloned into a different writable CacheAccess.
    Then, suppose incoming updates cause object and object2 to be related, where a subsequent CacheAccess::refresh() would pull object2 into the first writable CacheAccess. But, wait, it's already in the other writable CacheAccess. Does that cause an exception on the refresh()?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Request clarification on interface of DLRL object with multi-attribute

  • Key: INBOX-126
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    Does a Collection attribute have a setter?

    For example, suppose I have a Foo with a List<Long> in it (this isn't valid IDL, please humor me):

    valuetype Foo : DDS::ObjectRoot

    { public List<long> my_longs; }

    That generates a Foo::get_my_longs() in the target language. Should it also generate a Foo::set_my_longs() in the target language?

    Or should there simply be a Foo::get_my_longs(), and I modify the List<long> via add, put, etc?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Request clarification: what can you do with a deleted object?

  • Key: INBOX-125
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    If I have a handle on an object (such as a Foo), and the Foo is deleted from underneath me, I understand that I'll get an AlreadyDeleted exception if I try to do anything (call a setter or a getter) on the Foo.

    However, it seems like you should be able to get the OID and the read_state (which should be OBJECT_DELETED) from a deleted object. Can you? Can I call oid() and read_state() on a deleted object without getting an AlreadyDeleted exception?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Request clarification of how to handle a dangling related object

  • Key: INBOX-120
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    How should dangling relationships be handled?

    For example, suppose I have a Foo->Bar relationship. My Foo has a related Bar.

    1. I clone the Foo and the Bar into the CacheAccess.
    2. Someone deletes the Bar, but does not update the Foo's relationship.
    3. I refresh the CacheAccess, which deletes my Bar in the CacheAccess, but my Foo thinks it's still related.

    What should happen when I call Foo.get_bar()?

    a. throw an exception? (NotFound? AlreadyDeleted?)
    b. return a NULL?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

PIM Spec should have separate tables for Foo types, like DCPS section does

  • Key: INBOX-130
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    It would be helpful if the DLRL section's Platform-Independent Model broke out separate interface tables for its generated types, as the DCPS spec does with FooTypeSupport, FooDataReader, FooDataWriter, etc. This would enable the spec to clarify some slightly confusing tables, such as the table for a SelectionListener that shows on_object_in, on_object_out, and on_object_modified accepting an ObjectRoot parameter, when we really know it accepts a Foo. Breaking out a separate FooSelectionListener to demonstrate this would be useful, as it was for the DCPS section.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Need to clarify what is meant by "RELATED_OBJECTS"

  • Key: INBOX-108
  • Status: pending  
  • Source: MITRE ( Charlotte Wales)
  • Summary:

    Need to clarify what is meant by "RELATED_OBJECTS" – ObjectRoot has an is_modified method that takes a scope, OBJECT_ONLY, CONTAINED_OBJECTS and RELATED_OBJECTS. Whereas it is clear that OBJECT_ONLY means only attributes on this ObjectRoot and that CONTAINED_OBJECTS includes any changes to objects that this object refers to, it is not clear what RELATED_OBJECTS means.

  • Reported: DDS 1.1 — Fri, 14 Apr 2006 04:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

create_object and create_unregistered_object

  • Key: INBOX-114
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    DDS DLRL Issue: create_object and create_unregistered_object should
    throw PreconditionNotMet if keyType is incompatible Section 8.1.6.3.7, ObjectHome, add the following to these method descriptions:

    create_object: "The method throws a PreconditionNotMet if the Home is a NoOid Home"

    create_unregistered_object:"The method throws a PreconditionNotMet if the Home is a FullOid or SimpleOid Home"

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Give each CacheAccess its own Publisher and DataWriters

  • Key: INBOX-165
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    If one of the purposes of the CacheAccess is to separate sets of objects that are being manipulated by different threads from eachother, then it makes sense to also give them a separate Publisher. Otherwise different threads might try to write different coherent sets of information using the same DataWriters at the same time, thus mixing up two separate coherent sets as one big chunk. Also with respect to tailoring QoS settings the modifying threads might influence each-other.

    Solution:

    Giving each CacheAccess its own Publisher and DataWriters allows you to completely separate each thread of modification. Coherent Sets that are being written always have exactly the right coherence scope, and it is possible to have different CacheAccess objects for different purposes: for example one CacheAccess to write the objects reliably, another one to send them with best-effort.

    Creating a CacheAccess then implicitly creates a Publisher and all the required DataWriters for all ObjectHomes attached to the main Cache, using the same QoS settings as the writers already attached to the main Cache. To allow the user of a CacheAccess to tailor these QoS-settings, all these DCPS entities should be created in a disabled state. That means that the CacheAccess would require a new operation called 'enable' to enable them all. Also it means that since the CacheAccess will have its own Publisher, the 'the_publisher' attribute can be moved from the Cache to the CacheBase interface.

    Question is why a Cache still requires a Publisher if you are only allowed to write information from a CacheAccess. We see no reason why a Cache could not be used to write information as well: there are sufficient mechanisms available in DLRL to prevent manual modifications being overwritten by automatic updates: one could disable the automatic updates for this purpose, or one could do the modification during a listener callback, thus blocking new updates from being applied. Also for a WriteOnly application it makes sense to have a writeable Cache. We therefore also propose to move the write operation from the CacheAccess to the CacheBase class and to change the CacheAccess parameter in the create_object and create_unregistsred_object operations into a CacheBase operation.

    TBD.

  • Reported: DDS 1.2 — Thu, 15 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

section 3.2.2.3.2.13 MultiRelation - XML code

  • Key: INBOX-179
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.2.3.2.13 MultiRelation, the xml code still talks about a FullSimpleOID, it should be FullOid. The case is also wrong for the SimpleOid

    Solution:
    Replace:
    <multiRelation name="tracks">
    <multiPlaceTopic name="RADARTRACKS-TOPIC"
    <keyDescription content="SimpleOID">
    <keyField>RADAR-OID</keyField>
    </keyDescription>
    <\multiPlaceTopic>
    <keyDescription content="FullSimpleOID">
    <keyField>TRACK-CLASS</keyField>
    <keyField>TRACK-OID</keyField>
    </keyDescription>
    </multiRelation>
    With:
    <multiRelation name="tracks">
    <multiPlaceTopic name="RADARTRACKS-TOPIC"
    <keyDescription content="SimpleOid">
    <keyField>RADAR-OID</keyField>
    </keyDescription>
    <\multiPlaceTopic>
    <keyDescription content="FullOid">
    <keyField>TRACK-CLASS</keyField>
    <keyField>TRACK-OID</keyField>
    </keyDescription>
    </multiRelation>

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Figure 3-4 and section 3.2.1.2.2 Implied IDL

  • Key: INBOX-160
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The find_object operation is not listed in the ObjectHome class in figure 3-4 on page 3-16.

    Solution:
    Obvious

    Problem:
    In section 3.2.1.2.2 Implied IDL, typos in the FooHome defintion for the find_object_in_access. The operation no longer exists. The find_object operation is missing a parameter as well

    Solution:

    Replace:
    Foo find_object_in_access (in DDS::DLRLOid oid, in DDS::CacheAccess access)
    raises (DDS::NotFound);
    Foo find_object (in DDS::DLRLOid oid);
    With:
    Foo find_object (in DDS::DLRLOid oid, in DDS::CacheBase source);

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

section 3.2.2.3.2.13 MultiRelation, 3rd bullet

  • Key: INBOX-176
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    In section 3.2.2.3.2.13 MultiRelation, the 3rd bullet states a valueKey sub-tag, which does not exist! It should be keyDescription instead!

    Solution:
    Replace:
    This tag gives the mapping for a multi-valued relation. It has:
    o A mandatory attribute to give the name of the relation.
    o A mandatory sub-tag to give the DCPS Topic where it is placed (multiPlaceTopic - see Section 3.2.2.3.2.11).
    o One valueKey sub-tag (see Section 3.2.2.3.2.12).
    With:
    This tag gives the mapping for a multi-valued relation. It has:
    o A mandatory attribute to give the name of the relation.
    o A mandatory sub-tag to give the DCPS Topic where it is placed (multiPlaceTopic - see Section 3.2.2.3.2.11).
    o One keyDescription sub-tag (see Section 3.2.2.3.2.12).

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

section 3.2.1.2 IDL description on page 3-52

  • Key: INBOX-229
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.1.2 IDL description on page 3-52 the criterion attribute of the Selection interface is incorrectly defined within the comments section. It should simply be listed as an attribute, as it wont be generated in the specialized FooSelection. In the implied IDL in section 3.2.1.2.2 on page 3-60 a wrong attribute is stated as well (filter attribute, it should be removed).

    Solution:

    In section 3.2.1.2 IDL description on page 3-52 replace (only the beginning of the interface definition is shown):
    local interface Selection {
    // Attributes
    // ----------
    readonly attribute boolean auto_refresh;
    readonly attribute boolean concerns_contained;
    /***

    • Following attributes will be generated properly typed
    • in the generated derived classes
      *
      readonly attribute SelectionCriterion criterion;
      readonly attribute ObjectRootSeq members;
      readonly attribute SelectionListener listener;
      *
      */

    With:
    local interface Selection {
    // Attributes
    // ----------
    readonly attribute boolean auto_refresh;
    readonly attribute boolean concerns_contained;
    readonly attribute SelectionCriterion criterion;

    /* The following attributes will be generated properly typed

    • in the generated derived classes
      *
    • readonly attribute ObjectRootSeq members;
    • readonly attribute SelectionListener listener;
      */

    In the implied IDL in section 3.2.1.2.2 on page 3-60 replace:
    local interface FooSelection : DDS::Selection

    { readonly attribute FooFilter filter; readonly attribute FooSeq members; readonly attribute FooSelectionListener listener; FooSelectionListener set_listener ( in FooSelectionListener listener); }

    ;
    With:
    local interface FooSelection : DDS::Selection

    { readonly attribute FooSeq members; readonly attribute FooSelectionListener listener; FooSelectionListener set_listener ( in FooSelectionListener listener); }

    ;

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Typos in section 3.1.6.6

  • Key: INBOX-172
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The section 3.1.6.6 regarding generated classes contains many typos. It mentions the FooQuery class to be generated, but that is no longer the case! The queryCriterion class is all that is needed for query filters. In the Implied IDL on page 3-60, section 3.2.1.2.2 the local interface for Fooquery should be removed as well!
    It also mentions a FooRelation class, which no longer exists, and names the collection types incorrectly (FooListRelation should simply be FooList), etc.
    It also forgets to mention the FooSet class and the Foo class itself.

    Solution:
    Replace:
    Assuming that there is an application class named Foo (that will extend ObjectRoot), the following classes will be generated:
    o FooHome : ObjectHome
    o FooListener : ObjectListener
    o FooSelection : Selection
    o FooSelectionListener : SelectionListener
    o FooFilter : FilterCriterion
    o FooQuery : FooFilter, QueryCriterion
    o And for relations to Foo objects (assuming that these relations are described in the applicative mode - note also that the actual name of these classes will be indicated by the application):
    o "FooRelation" : RefRelation
    o "FooListRelation" : ListRelation
    o "FooStrMapRelation" : StrMapRelation
    o "FooIntMapRelation" : IntMapRelation
    With:
    Assuming that there is an application class named Foo (that will extend ObjectRoot), the following classes will be generated:
    o Foo: ObjectRoot
    o FooHome : ObjectHome
    o FooListener : ObjectListener
    o FooSelection : Selection
    o FooSelectionListener : SelectionListener
    o FooFilter : FilterCriterion
    o FooList : List
    o FooStrMap : StrMap
    o FooIntMap : IntMap
    o FooSet : Set

    On page 3-60 in section 3.2.1.2.2 remove:
    local interface FooQuery : DDS::QueryCriterion, FooFilter {
    };

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Typo in section 3.1.6.1.2.1

  • Key: INBOX-193
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The last sentence of section 3.1.6.1.2.1 is in conflict with section 3.1.6.3.4 which states that a missing object home (i.e. no subscription exists) raises a BadHomeDefinition (see details on the register_all_for_pubsub operation). Making navigation to an object for which no subscription exists impossible.

    The BadHomeDefinition option is superior, as it forces application developers to think about their local object model and remove relations they do not need, not only to object home they happened not to register, but also relations between object homes they have registered. The power of DLRL is in the fact each application can tailor the object model to it's own specific needs, removing relations from DLRL management which are simply not of any interest (this is a performance saver!).
    It's also undesirable to ignore missing object homes and just return a NotFound exception as it's not clear to an application developer that these exceptions are occuring because he forgot to register a home, the bad home definition makes things much more explicit, without a loss in flexibility.

    Solution:
    Replace:
    If a relation points towards an object for which no subscription exists, navigating through that relation will raise an error (NotFound).
    With:
    If a relation points towards an object for which no subscription exists, a BadHomeDefinition exception is raised when the Cache is registered for publication/subscription.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Typo in section 3.1.4.2.1

  • Key: INBOX-159
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Section 3.1.4.2.1 speaks of tables and rows, it is suggested to change this into topics and instances to correspond better with DCPS terminology.
    It is also suggested to speak of 'fields to uniquely identify the object' instead of 'fields needed to store a reference to that object'.
    It is also wise to change the word application in the last sentence of the last paragraph to implementation, as this mechanism is worked out by a DLRL implementation, not an application.

    Solution:

    Replace:
    Each DLRL class is associated with at least one DCPS table, which is considered as the 'main' table. A DLRL object is considered to exist if it has a corresponding row in this table. This table contains at least the fields needed to store a reference to that object (see below).

    To facilitate DLRL management and save memory space, it is generally desirable that a derived class has the same main table as its parent concrete class (if any)5, with the attributes that are specific to the derived class in an extension table. For example, this allows the application to load all the instances of a given class (including its derivations) in a single operation.

    With:
    Each DLRL class is associated with at least one DCPS topic, which is considered as the 'main' topic. A DLRL object is considered to exist if it has a corresponding instance in this topic. This topic contains at least the fields to uniquely identify the object (see below).

    To facilitate DLRL management and save memory space, it is generally desirable that a derived class has the same main topic as its parent concrete class (if any)5, with the attributes that are specific to the derived class in an extension topic. For example, this allows the implementation to load all the instances of a given class (including its derivations) in a single operation.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Describe exact behaviour of compositions and associations in the DLRL.

  • Key: INBOX-183
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    It is possible to annotate certain relations in the XML as being compositions and/or associations. Section 3.1.3.2.2 briefly describes how such relationships should behave. However, although it is possible to enforece constraints on certain relationships on the writer side, it is not possible to enforece them on the reader side. Especially not since the constraints are part of the 'local' object model, while the topics sould have been written by somebody with another 'local' model where these constraints are not enforced.
    What should happen to a composition relation where multiple objects claim possession of the same compound object? Or to an association where the associated object does not refer back to the object that associates it?

    Solution:

    In our opinion these constraints can only be enforced in the local object model, not on the entire system. (Unless of course the entire system shares the same object model). Because of this we propose to enforece these constraints only on the writer side of the DLRL: when objects in a writeable CacheAccess are modified and do not adhere to these constraints, the write operations will raise an InvalidObjects (See also issue PT-DLRL-ARCH-0008).

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

objects instances in a writeable CacheAccess

  • Key: INBOX-162
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    When should objects instances in a writeable CacheAccess be regsitered to the DataWriter? Upon entrance into the writeable CacheAccess or only when actually performing the write operation. This choice may impact ownership matters. Same question for newly created objects in a CacheAccess: when should they be registered?

    Solution:

    Our proposal is to only register any changes during the write operations, otherwise overhead is very heavy when cloning a large tree of Objects into a writeable CacheAccess. Probably most of these objects will not become modified and then doing a register upon entrance of each instance might result in huge numbers of unnecessary register messages.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Selection should have a non-listener way of obtaining the members

  • Key: INBOX-227
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    The only way to find out which objects were inserted into/modified in/removed from a Selection is by attaching a SelectionListener to that Selection and by processing the callbacks on these events. However, there should also be a way to obtain this information without having to resort to Listeners.

    Solution:

    Add operations to the Selection that return a list of objects that are inserted into/modified in/removed from that Selection.

    Section 3.1.6.2, Figure 3-4: Add 3 operations to the Selection called "get_inserted_members", "get_modified_members" and get_removed_members".

    Section 3.1.6.3.9: Add the following entry to the table:
    Selection
    operations
    get_inserted_members <undefined>[]
    get_modified_members <undefined>[]
    get_removed_members <undefined>[]

    Section 3.1.6.3.9
    Add:

    · get_inserted_members returns all objects that entered the Selection in the current update round.
    · get_modified_members returns all objects still belonging to the Selection whose content has changed in the current update round.
    · get_removed_members returns all objects that exited the Selection in the current update round.

    Section 3.2.1.2.1: In the following lines of the Generic IDL of the Selection interface:
    Replace:

    /***

    • Following method will be generated properly typed
    • in the generated derived classes
      *
      SelectionListener set_listener (
      in SelectionListener listener);
      *
      ***/

    With:

    /***

    • Following method will be generated properly typed
    • in the generated derived classes
      *
      SelectionListener set_listener (in SelectionListener listener);
      ObjectRootSeq get_inserted_members ( );
      ObjectRootSeq get_modified_members ( );
      ObjectRootSeq get_removed_members ( );
      *
      ***/

    Section 3.2.1.2.2: In the Implied IDL of the FooSelection interface add the following lines:

    FooSeq get_inserted_members ( );
    FooSeq get_modified_members ( );
    FooSeq get_removed_members ( );

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

The classname in FullOid makes no sense in case of a 'local' Object model

  • Key: INBOX-186
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    When using a keyDescription set to "FullOid" in the XML mapping file, each OID field is accompanied by a class-name field that represents the actual type of a specific object instance (i.e. the name of the class that that object instance was instantiated to.)
    However, in case of a purely 'local' object model, this class name has no meaning outside the scope of the application that uses this local model. If the topics used for transport are also mapped to another 'local' object model, you get a confusing mix of local and global information in the same topic. This sort of confusion should be avoided at all costs: topics may only transport information that refers to the global information model, not to some local representation of it.

    Solution:

    Either allow the FullOid tag to only be used in case of a 'global' object model (default mapping, topic model is generated to match it), or describe that the class-name should not represent the name of a 'local' DLRL class, but rather the name of the topic that represents the state of that 'local' class.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Introduce the clear() operation on the Collection interface.

  • Key: INBOX-170
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    It would be convient to have a clear() operation on the collection interface which simply removes all elements from the collection (does not effect added/modified/deleted _elements operations results…). While we are at it, remove the type in the table stating there are no attributes as well (since two attributes are listed!!).

    Solution:
    Replace:
    Collection
    no attributes
    length integer
    values Undefined [] (e.g. of type ObjectRoot or Primitive type)

    It provides the following attributes:
    o length - the length of the collection.
    o values - a list of all values contained in the Collection.

    With:
    Collection
    attributes
    length integer
    values Undefined [] (e.g. of type ObjectRoot or Primitive type)
    operations
    clear void

    It provides the following attributes:
    o length - the length of the collection.
    o values - a list of all values contained in the Collection.

    It provides the following methods:
    · clear - to clear the contents of the Collection, does not affect the added_elements, modified_elements, deleted_elements results. If the object this Collection belongs to is not registered or does not belong to a (writeable) CacheAccess a PreconditionNotMet is raised

    In the IDL description on page 3-55 add the following to the abstract valuetype Collection:
    void clear() raises(PreconditionNotMet);

    In figure 3-4 on page 3-16 the clear() operation should be added to the operation listing of class Collection

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Add an attribute to get the home_index

  • Key: INBOX-202
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    It would be convient (and performance reasons desirable) to get the index of the home associated with an ObjectRoot in one call, this would especially be usefull in combination with the contained_types operation on the CacheAccess.

    Solution:
    Add the following row to the attributes listing of the ObjectRoot directly following the row for attribute owner:
    home_index integer

    Add the following description to the list of description for attributes on page 3-21 directly following the description of attribute owner:
    o the index (home_index) under which it's related ObjectHome is registered to the Cache
    On Section 3.2.1.2 IDL description on page 3-51 regarding valuetype ObjectRoot add the attribute description:
    readonly long home_index;

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Unregistered objects

  • Key: INBOX-205
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    It is not clear what the read_state and write_state should be of an unregistered object.

    Solution:

    Set both states to VOID until the object gets registered.

    Section 3.1.6.3.7
    Replace:

    · pre-create a new DLRL object in order to fill its content before the allocation of the oid (create_unregistered_object); this method takes as parameter the CacheAccess concerned with this operation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Not satisfying either precondition will raise a PreconditionNotMet.

    With:

    · pre-create a new DLRL object in order to fill its content before the allocation of the oid (create_unregistered_object); this method takes as parameter the CacheAccess concerned with this operation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Not satisfying either precondition will raise a PreconditionNotMet. An unregistered object has both its read_state and its write_state set to VOID, and may only be used to assign a unique combination of key-values to it. The object should be registered before anything else can be done with it.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

non-existing elements

  • Key: INBOX-133
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    It is not clear what will happen when someone tries to obtain or remove a non-existing element from a Collection type (i.e. use the get/remove operation with a non-existing key/index). The NoSuchElement Exception was meant for that purpose.

    Solution:

    Explicitly mention the siutuations in which the NoSuchElement exception will be raised.

    Section 3.1.6.3.16
    Replace:

    · "remove - to remove the item with the highest index from the collection.
    · "get - to retrieve an item in the collection (based on its index).

    With:

    · remove - to remove the item with the highest index from the collection. If the List is already empty, a NoSuchElement is raised.
    · get - to retrieve an item in the collection (based on its index). If the specified index is greater than or equal to the length of the List, a NoSuchElement is raised.

    Section 3.1.6.3.17
    Replace:

    · "remove - to remove an element from the Set. If the specified element is not contained in the Set, the operation is ignored.

    With:

    · remove - to remove an element from the Set. If the specified element is not contained in the Set, a NoSuchElement is raised.

    Section 3.1.6.3.18 AND 3.1.6.3.19
    Replace:

    · "remove - to remove an item from the collection.
    · "get - to retrieve an item in the collection (based on its key).
    With:

    · remove - to remove an item from the collection. If no item matches the specified key, a NoSuchElement is raised.
    · get - to retrieve an item in the collection (based on its key). If no item matches the specified key, a NoSuchElement is raised.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Cache

  • Key: INBOX-166
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    It is not clear whether it is allowed to create a CacheAccess when the Cache is not yet in enabled mode. Since the CacheAccess is not usable until the Cache is enabled, it makes sense not to allow the creation of a CacheAccess in that case.

    Solution:

    Make clear that a PreconditionNotMet is raised when a CacheAccess is created in a Cache that is not yet enabled.

    Section 3.1.6.3.4
    Replace:

    The purpose of the CacheAccess must be compatible with the usage mode of the Cache: only a Cache that is write-enabled can create a CacheAccess that allows writing. Violating this rule will raise a PreconditionNotMet:

    With:

    The Cache must have its pubsub_state set to ENABLED before it is allowed to create a CacheAccess. Furthermore, the purpose of the CacheAccess must be compatible with the usage mode of the Cache: only a Cache that is write-enabled can create a CacheAccess that allows writing. Violating any of these rules will raise a PreconditionNotMet.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

The generated class FooImpl is not mentioned in the implied idl

  • Key: INBOX-167
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.1.2.2 Implied IDL add directly after the definition of the Foo valuetype:

    valuetype FooImpl : Foo

    { //place for application to implement application defined operations // (operations signature known at Foo level!) }

    ;

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

The Implied IDL needs to be extended with attribute examples for class Foo

  • Key: INBOX-188
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In the implied IDL section 3.2.1.2.2 on page 3-59 it shows what classes/operation are generated for a fictional type Foo. However this example is too simplistic, it would be helpful to extend the example for valuetype Foo, so that the valuetype contains one simple attribute, one simple key field attribute and one mono relation and one multi relation, as an example to what methods are generated because of such attributes.

    Our suggestion is to add the following attributes to the Foo class:
    public long x; //keyfield of the underlying topic
    public long y;
    public Bar a_bar;
    public BarSet bars;

    The Bar class itself is left out of consideration for the example.

    Solution:
    Replace:
    This section contains the implied IDL constructs for an application-defined class named
    Foo.
    #include "dds_dlrl.idl"
    valuetype Foo: DDS::ObjectRoot

    { // some attributes and methods }

    ;
    With:
    This section contains the implied IDL constructs for an application-defined class named
    Foo. For example purposes several attributes are defined on Foo. Namely:
    · public long x (keyfield of the underlying Foo topic)
    · public long y (a regular field)
    · public Bar a_bar (mono relation to a Bar DLRL object)
    · public BarSet bars (multi relation of Bar DLRL objects)
    The related Bar classes are not worked out in the implied IDL, but just mentioned as forward valuetype defintions.
    #include "dds_dlrl.idl"

    //forward declarations of Bar and it's helper classes. Bar itself is not worked out
    //in the implied IDL
    valuetype Bar;
    valuetype BarSet;

    valuetype Foo: DDS::ObjectRoot

    { //getter methods for all attributes long get_x(); long get_y(); Bar get_a_bar() raises (DDS::NotFound); BarSet get_bars(); //setter methods for all attributes void set_x(long val) raises (DDS::PreconditionNotMet); void set_y(long val) raises (DDS::PreconditionNotMet); void set_a_bar(Bar val) raises (DDS::PreconditionNotMet); void set_bars(BarSet val) raises (DDS::PreconditionNotMet); //is_xxx_modified methods for all attributes boolean is_x_modified(); boolean is_y_modified(); boolean is_a_bar_modified(DDS::ReferenceScope scope); boolean is_bars_modified(DDS::ReferenceScope scope); }

    ;

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

(last) end_updates call on CacheListeners

  • Key: INBOX-155
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    It is currently not clear that the modification states are cleared after the last call to the CacheListener (multiple cache listeners may be registered!). This should be clarified.

    Solution:
    Replace:
    o Finally all the CacheListener::end_updates operations are triggered and the modification states of the updated objects is cleaned; the order in which these listeners are triggered is not specified.

    With:
    o Finally all the CacheListener::end_updates operations are triggered and the modification states of the updated objects is cleaned after the last CacheListener::end_updates has been triggered; the order in which these listeners are triggered is not specified.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify text on page 3-35 directly following the operation descriptions.

  • Key: INBOX-207
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The text following the operation descriptions of the ObjectRoot on page 3-35 talks about state transitions taking place between the start of an update round and the end of an update round. This is confusing. It should state that state transitions are applied directly following the start of an update round and are cleared directly following the end of an update round.

    Solution:

    Replace:
    A Cache Object represents the global system state. It has a read_state whose transitions represent the updates as they are received by the DCPS. Since Cache Objects cannot be modified locally, they have no corresponding write_state (i.e. their write_state is set to VOID). State transitions occur between the start of an update round and the end of of an update round. When in automatic updates mode, the start of the update round is signaled by the invocation of the on_begin_updates callback of the CacheListener, while the end of an update round is signaled by the invocation of the on_end_updates callback of the CacheListener. When in manual update mode, the start of an update round is defined as the start of a refresh operation, while the end of an update round is defined as the invocation of the next refresh operation.

    With:
    A Cache Object represents the global system state. It has a read_state whose transitions represent the updates as they are received by the DCPS. Since Cache Objects cannot be modified locally, they have no corresponding write_state (i.e. their write_state is set to VOID). State transitions are applied directly following the start of an update round and are cleared directly following the end of an update round. When in automatic updates mode, the start of the update round is signaled by the invocation of the on_begin_updates callback of the CacheListener, while the end of an update round is signaled by the invocation of the on_end_updates callback of the CacheListener. When in manual update mode, the start of an update round is defined as the start of a refresh operation, while the end of an update round is defined as the invocation of the next refresh operation.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of the destroy() operation on the ObjectRoot

  • Key: INBOX-144
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    It should be clarified that a destroyed ObjectRoot is only removed from the CacheAccess after the write() operation has been performed. The ObjectRoot will produce AlreadyDeleted exceptions only after that time.

    Solution:
    Replace:
    o mark the object for destruction (destroy), to be executed during a write operation. If the object is not located in a writeable CacheAccess, a PreconditionNotMet is raised.
    With:
    o mark the object for destruction (destroy), to be executed during a write operation on the owning CacheAccess. After the write operation has been completed the object will be removed from the CacheAccess and subsequent calls to operations on the object may result in AlreadyDeleted exceptions being raised. If the object is not located in a writeable CacheAccess, a PreconditionNotMet is raised.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

getter/setter/is_modified operations

  • Key: INBOX-226
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    For each attribute a getter, setter and is_xxx_modified (in case of non-keyfields) operation is to be generated in the derived class. This should be made more explicity by adding the operations in the table contents on page 3-34. It should also be added in the IDL description in section 3.2.1.2 on page 3-51 and in figure 3-4 on page 3-16

    Since keyfields determine the identity of a DLRL object, they cannot be changed. That means no is__<attribute>_modified operations needs to be generated for them.

    Solution:
    Add the following to the table on page 3-34:
    For each attribute defined on the class:
    get_<attribute_name> <undefined attribute type>
    set_<attribute_name> void
    value <undefined attribute type>
    For each attribute defined on the class which is not a relation to another DLRL object:
    is_<attribute_name>_modified boolean
    For each attribute defined on the class which is a relation (mono relation / multi relation) to another DLRL object:
    is_<attribute_name>_modified boolean
    scope ReferenceScope

    Section 3.1.6.3.14:
    Replace:

    · is_<attribute>_modified, to get if this attribute has been modified by means of incoming modifications (cf. method is_modified).

    With:

    · is_<attribute_name>_modified, to get if this attribute has been modified by means of incoming modifications (cf. method is_modified). Since keyfields cannot be changed by incoming modifications, this operation will not be generated for attributes that represent such keyfields.

    Add the following text in the description for valuetype ObjectRoot on page 3-51 in section 3.2.1.2 within the closing bracket of the objectroot valuetype.
    /* For each attribute of the application type 'Foo' the following operations

    • will be generated:
    • <attribute_type> get_<attribute_name>();
    • void set_<attribute_name>(<attribute_type> value);
    • If the attribute is a MonoAttribute or MultiAttribute the following operation will
    • be generated:
      *
    • boolean is_<attribute_name>_modified();
      *
    • If the attribute is a MonoRelation or MultiRelation the following operation will
    • be generated:
      *
    • boolean is_<attribute_name>_modified(ReferenceScope scope);
      */

    Add in figure 3-4 on page 3-16 to the ObjectRoot class operations listing the following operations:
    get_<attribute_name>()
    set_<attribute_name>()
    is_<attribute_name>_modified()

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

In section 3.1.6.3.7 regarding the ObjectHome clarify some things

  • Key: INBOX-147
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem 1
    The description for the name attribute (see issue XXX) needs to be clarified into saying that the name attribute gives the fully qualified name using IDL '::' as seperators (i.e. ObjectHome representing class Foo in module test has as name 'test::Foo').

    Solution 1:
    Replace:
    o the public name of the application-defined class (name).
    With:
    o the public fully qualified name (using IDL seperators '::') of the application-defined class (name). For an ObjectHome representing class Foo in module test it's name becomes 'test::Foo'.

    Problem 2:
    The description for the index attribute of the object home needs to specify what the index is in case the home is not yet registered with any Cache. It is our suggestion to make this operation return -1 as value for an ObjectHome which has not yet been registered to any Cache. The description also contains a type, as it talks about index, but it should be registration_index.

    Solution 2:
    Replace:
    o the index under which the ObjectHome has been registered by the Cache (see Cache::register_home operation).
    With:
    o the index (registration_index) under which the ObjectHome has been registered by the Cache (see Cache::register_home operation). If the ObjectHome was not yet registered to any Cache then -1 is returned as value.

    In the IDL description in section 3.2.1.2 on page 3-53 the attribute type of the registration_index needs to be replaced from unsigned_long to long to allow -1 as return value.
    Replace:
    readonly attribute unsigned long registration_index;
    With:
    readonly attribute long registration_index;

    In the IDL description in section 3.2.1.2 on page 3-58 regarding the Cache interface description change the return value of the register_home operation from unsigned_long into long:
    Replace:
    unsigned long register_home (
    in ObjectHome a_home)
    raises (
    PreconditionNotMet);
    With:
    long register_home ( in ObjectHome a_home) raises (PreconditionNotMet);

    Problem 3:
    The description for the selections and listeners attributes should be in plural, furthermore the attribute names in the description should be bold .

    Solution 3:
    Replace:
    o the list of attached Selection (selections).
    o the list of attached ObjectListener (listeners).
    With:
    o the list of attached Selection objects (selections).
    o the list of attached ObjectListener objects (listeners).

    Problem 4:
    The description for the set_content_filter operation states that it can only be set before the home is registered to a Cache. But this is not correct, it should state that it must be set while the cache the home is registered to (if any) has a pubsub state of INITIAL. As long as the readers have not been created it should not be prohibited to set the content filter.

    Solution 4:
    Replace:
    o set the content_filter for that ObjectHome (set_content_filter). As a content filter is intended to be mapped on the underlying infrastructure it can be set only before the ObjectHome is registered (see Cache::register_home). An attempt to change the filter expression afterwards will raise a PreconditionNotMet. Using an invald filter expression will raise an SQLError.
    With:
    o set the content_filter for that ObjectHome (set_content_filter). As a content filter is intended to be mapped on the underlying infrastructure it can be set only if the Cache to which the ObjectHome belongs (if any) has not yet been registered for pubsub. (see Cache::register_all_for_pubsub). An attempt to change the filter expression afterwards will raise a PreconditionNotMet. Using an invald filter expression will raise an SQLError.

    Problem 5:
    The description of the deref_all operation talks about the 'most recent' state, but this is not correct. As in 'manual' update mode (using the refresh operation on the Cache) one wants to load the state as known during the last refresh operation, which is not neccesarily the most recent state known in DCPS. Reasoning behind this is that one doesn't want to have inconcistent states within the DLRL, where one object state is significantly 'newer' then other states, especially since 'dereferencing' is only meant to load in a state which is not done at refresh time to gain performance. The deref_all is not meant as a refresh on home level!

    Solution 5:
    Replace:
    o ask to load the most recent state of a DLRL Object into that Object for all objects managed by that home (deref_all).
    With:
    o ask to load the last known state (at the time of the last update round) of a DLRL Object into that Object for all objects managed by that home (deref_all).

    Problem 6:
    The description about the create_selection operation talks about a SelectionCriteration (second line) where it should talk about a QueryCriterion. In the last line it should clarify that the PreconditionNotMet is raised if the cache it belongs to is still set to INITIAL with relation to the DCPS state as well as if the home does not yet belong to a Cache.

    Solution 6:
    Replace:
    o create a Selection (create_selection). The criterion parameter specifies the SelectionCriterion (either a FilterCriterion or an SelectionCriterion) to be attached to the Selection, the auto_refresh parameter specifies if the Selection has to be refreshed automatically or only on demand (see Selection) and a boolean parameter specifies, when set to TRUE, that the Selection is concerned not only by its member
    objects but also by their contained ones (concerns_contained_objects); attached SelectionCriterion belong to the Selection that itself belongs to its creating ObjectHome. When creating a Selection while the DCPS State of the Cache is still set to INITIAL, a PreconditionNotMet is raised.
    With:
    o create a Selection (create_selection). The criterion parameter specifies the SelectionCriterion (either a FilterCriterion or an QueryCriterion) to be attached to the Selection, the auto_refresh parameter specifies if the Selection has to be refreshed automatically or only on demand (see Selection) and a boolean parameter specifies, when set to TRUE, that the Selection is concerned not only by its member
    objects but also by their contained ones (concerns_contained_objects); attached SelectionCriterion belong to the Selection that itself belongs to its creating ObjectHome. When creating a Selection if the ObjectHome does not yet belong to a Cache or while the DCPS State of the Cache that the ObjectHome belongs to is still set to INITIAL, a PreconditionNotMet is raised.

    Problem 7:
    The description of the create_unregistered_object should be changed to indicate that only the identity should be set/changed for objects created by this operation. One wants to prevent relations and such to be set on unregistered objects. The only reason this operation exists is to allow an application to set the identity of the object if the object is mapped using predefined mapping rules. In this mode the DLRL cannot determine the keys itself and thus needs user input.

    Solution 7:
    Replace the word 'content' on the first line with 'identity'.

    Problem 8:
    Clarify the register_object method only takes objects created by the create_unregistered_object method of the same home instance.

    Solution 8:
    Replace:
    o register an object resulting from such a pre-creation (register_object). This operation embeds a logic to derive from the object content a suitable oid; only objects created by create_unregistered_object can be passed as parameter, a PreconditionNotMet is raised otherwise. If the result of the computation leads to an
    existing oid, an AlreadyExisting exception is raised. Once an object has been registered, the fields that make up its identity (i.e. the fields that are mapped onto the keyfields of the corresponding topics) may not be changed anymore.
    With:
    o register an object resulting from such a pre-creation (register_object). This operation embeds a logic to derive from the object content a suitable oid; only objects created by create_unregistered_object (of the same ObjectHome instance) can be passed as parameter, a PreconditionNotMet is raised otherwise. If the result of the computation leads to an
    existing oid, an AlreadyExisting exception is raised. Once an object has been registered, the fields that make up its identity (i.e. the fields that are mapped onto the keyfields of the corresponding topics) may not be changed anymore.

    Problem 9:
    Clarify behavior for the find_object operation if no object with the specified OID can be located. (return NULL). It is not desireable to throw an exception if no object can be found (Notfound) as that is too heavy wait just to report that no object with the specified OID exists..

    Solution 9:
    Replace:
    o retrieve a DLRL object based on its oid in the in the specified CacheBase (find_object).
    With:
    o retrieve a DLRL object based on its oid in the in the specified CacheBase (find_object). If no such object can be located NULL is returned.

    In the IDL description on page 3-54 in section 3.2.1.2 regarding the ObjectHome replace:
    ObjectRoot find_object (
    in DLRLOid oid,
    in CacheBase source)
    raises (
    NotFound);
    With:
    ObjectRoot find_object ( in DLRLOid oid, in CacheBase source);

    Problem 10:
    Clarify the behavior of the get_topic_name operation if the passed attribute is not defined within the home. (it should just return NULL)

    Solution 10:
    Replace:
    o retrieve the name of the topic that contains the value for one attribute(get_topic_name). If the DCPS State of the Cache is still set to INITIAL, a PreconditionNotMet is raised.
    With:
    o retrieve the name of the topic that contains the value for one attribute (get_topic_name), if the attribute is unknown then NULL is returned. If the DCPS State of the Cache is still set to INITIAL, a PreconditionNotMet is raised.

    Problem 11:
    It should be clarified that objects with the state DELETED should not be contained in the get_objects operation of the ObjectHome. The text about ObjectRoot turning into Foo should also be removed, as its already covered by the undefined bit see XXX.

    Solution 11:
    Replace:
    o obtain from a CacheBase a (typed) list of all objects that match the type of the selected ObjectHome (get_objects). For example the type ObjectRoot[ ] will be substituted by a type Foo[ ] in a FooHome.
    With:
    o obtain from a CacheBase a (typed) list of all objects that match the type of the selected ObjectHome (get_objects). Objects with the state DELETED are not contained within this list.

    Problem 12:

    Remove the text about ObjectRoot becoming Foo in the generated home for the description of the get_created_objects, get_modified_objects, get_deleted_objects. Its already stated with the undefined bit… See XXX

    Solution 12:
    Replace:
    o obtain from a CacheBase a (typed) list of all objects that match the type of the selected ObjectHome and that have been created, modified or deleted during the last refresh operation (get_created_objects, get_modified_objects and get_deleted_objects respectively). The type ObjectRoot[ ] will be substituted by a type Foo[ ] in a FooHome.
    With:
    o obtain from a CacheBase a (typed) list of all objects that match the type of the selected ObjectHome and that have been created, modified or deleted during the last refresh operation (get_created_objects, get_modified_objects and get_deleted_objects respectively).

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify various things with operation enable_all_for_pubsub

  • Key: INBOX-221
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.3.4 on page 3-23 regarding the operation enable_all_for_pubsub several clarifications should be made:
    1) In the first sentence before the word 'QoS' is should say (immutable) to clarify it's mainly the idea that immutable QoS settings can be changed at that time.
    2) The expression "those two operations" in the second sentence should be replaced by "this operation and the register_all_for_pubsub operation".
    3) It should state the DCPSError is raised if an error occurred while enabling the DCPS entities.

    Solution:
    Replace:
    o enable the derived Pub/Sub infrastructure (enable_all_for_pubsub). QoS setting can be performed between those two operations. One precondition must be satisfied before invoking the enable_all_for_pub_sub method: the pubsub_state must already have been set to REGISTERED before. A PreconditionNotMet Exception is thrown otherwise. Invoking the enable_all_for_pub_sub method on an ENABLED pubsub_state will be considered a no-op.

    With:
    o enable the derived Pub/Sub infrastructure (enable_all_for_pubsub). Changes to the (Immutable) QoS settings can be performed between this operation and the register_all_for_pubsub operation. One precondition must be satisfied before invoking the enable_all_for_pub_sub method: the pubsub_state must already have been set to REGISTERED before. A PreconditionNotMet Exception is thrown otherwise. A DCPSError is raised if an error occurred while enabling the DCPS entities. Invoking the enable_all_for_pub_sub method on an ENABLED pubsub_state will be considered a no-op.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exceptions with operation register_all_for_pubsub

  • Key: INBOX-163
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Description of the register_all_for_pubsub operation on page 3-23 in section 3.1.6.3.4 doesn't say under which conditions the DCPSError exception is raised

    Solution:
    Add the following sentence to the description of the register_all_for_pubsub operation:
    A DCPSError is raised if an error was encountered while trying to create the DCPS entities

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Unclarities in table in section 3.1.6.2 the row regarding the CacheAccess

  • Key: INBOX-178
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In the table in section 3.1.6.2 in the row regarding the CacheAccess it should be clarified that one CacheAccess should be used by one thread. If multiple threads require access to the same CacheAccess it is the application responsibility to ensure thread safety.

    Solution:
    Replace:
    Class that encapsulates the access to a set of objects. It offers methods to refresh and write objects attached to it; CacheAccess objects can be created in read mode, in order to provide a consistent access to a subset of the Cache without blocking the incoming updates or in write mode in order to provide support for concurrent modifications/updates threads.

    With (sentence at the end added):

    Class that encapsulates the access to a set of objects. It offers methods to refresh and write objects attached to it; CacheAccess objects can be created in read mode, in order to provide a consistent access to a subset of the Cache without blocking the incoming updates or in write mode in order to provide support for concurrent modifications/updates threads. A CacheAccess should only be used by one thread, if multiple threads require access to the same CacheAccess then it is the responsibility of the application to ensure thread safety.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Mismatch between DLRL and CORBA on enumerations

  • Key: INBOX-121
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The DLRL spec indicates that enumerations are mapped to 8-bit integers or strings, not to IDL enums. See 3.1.4.2.3

    Can that be right? An IDL enum is a 32-bit integer. See 3.11.2.4 in the 04-03-01 CORBA spec. It seems strange not to map a DLRL enum to an IDL enum. Is there a reason?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Error in the IDL for the SelectionListener

  • Key: INBOX-128
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The IDL for SelectionListsner has an error.

    The base SelectionListener class shows on_object_out() accepting an ObjectRoot; but the generated FooSelectionListener shows on_object_out (correctly) accepting a Foo. Putting the base SelectionListener's on_object_out() inside of the comment would fix this.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Should "set" method called outside of writable CacheAccess throw exception?

  • Key: INBOX-118
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    A set_<attribute> call on a DLRL object is only valid from within a writable CacheAccess. It seems that, if an application calls set_<attribute> on a DLRL object outside of a writable CacheAccess, then set_<attribute> should throw an exception – probably a PreconditionNotMet exception. However, the spec doesn't indicate that an exception should be thrown in this case. It only mentions the case where the attribute is a key field in the non-default mapping (3.1.6.3.14)

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

clarify behavior of content_filters in an inheritance hierarchy

  • Key: INBOX-113
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    Add the following to 8.1.6.3.7, ObjectHome::set_content_filter:

    "An object must pass all content filters in its Home and its base Homes to be accepted into the Cache"

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Specify names of mono-relation and multi-relation fields for default mappin

  • Key: INBOX-111
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    In section 8.1.4.3, add:

    o For a mono-relation called "bar", the mono-relation's oid fields are "bar_class" and "bar_oid".

    o For a multi-relation, the related object's oid and class fields are "value_oid" and "value_class".

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

use case for multiple valueFields

  • Key: INBOX-149
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    The DTD , the monoAttribute and multiAttribute elements allow multiple valueField elements to be specified inside them. It is not explained for which use-cases something like that would be convenient.

    Solution:

    In case the attribute is a struct, it could be used to map it directly onto multiple value Fields in the topic using the order in which the members of the struct are mentioned. (However, for such cases it might be better to map each struct member individually using its scoped name to avoid confusion.) It could also make sense to use it for elements inside an array.

    However, the exact use-case for which this is allowed should be mentioned explicitly, referably with good examples.

    TBD.

  • Reported: DDS 1.2 — Thu, 15 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

In section 3.2.3.5 Code example, several typos

  • Key: INBOX-174
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.3.5 Code example on page 3-74 and 3-75 several typos can be found. It talks about a DLRL module, which should be DDS in the definition of the CacheFactory variable and Cache variable.
    The create_cache operation is missing a parameter (cache name).
    The home objects should have their default constructors called.
    The create_object operations sometimes has a - as seperator instead of a _.
    The create_object should take a cache access as parameter instead of the cache, this cache access should also be created.
    The write operation should be performed on the created cache access, not on the cache.
    The closing }; should also be removed, as it is never opened.
    The setter operation for the operations are also incorrect. They should be set_x, not x. And the relation has a put operation which does not exist.
    The first setter for the a_radar attribute should operate on t1, not t2.

    Solution:

    Replace:
    DDS::DomainParticipant_var dp;
    DLRL::CacheFactory_var cf;
    /*

    • Init phase
      */
      DLRL::Cache_var c = cf->create_cache (WRITE_ONLY, dp);
      RadarHome_var rh;
      TrackHome_var th;
      Track3DHome_var t3dh;
      c->register_home (rh);
      c->register_home (th);
      c->register_home (t3dh);
      c->register_all_for_pubsub();
      // some QoS settings if needed
      c->enable_all_for_pubsub();
      /*
    • Creation, modifications and publication
      */
      Radar_var r1 = rh->create_object(c);
      Track_var t1 = th->create-object (c);
      Track3D_var t2 = t3dh->create-object (c);
      t1->w(12);// setting of a pure local attribute
      t1->x(1000.0);// some DLRL attributes settings
      t1->y(2000.0);
      t2->a_radar->put(r1);// modifies r1->tracks accordingly
      t2->x(1000.0);
      t2->y(2000.0);
      t2->z(3000.0);
      t2->a_radar->put(r1);// modifies r1->tracks accordingly
      c->write();// all modifications are published
      };
      With:
      DDS::DomainParticipant_var dp;
      DDS::CacheFactory_var cf;
      /*
    • Init phase
      */
      DDS::Cache_var c = cf->create_cache ("a_cache", WRITE_ONLY, dp);
      RadarHome_var rh = new RadarHome();
      TrackHome_var th = new TrackHome();
      Track3DHome_var t3dh = new Track3DHome();
      c->register_home (rh);
      c->register_home (th);
      c->register_home (t3dh);
      c->register_all_for_pubsub();
      // some QoS settings if needed
      c->enable_all_for_pubsub();
      /*
    • Creation, modifications and publication
      */
      DDS:CacheAccess_var ca = c->create_access(WRITE_ONLY);
      Radar_var r1 = rh->create_object(ca);
      Track_var t1 = th->create_object (ca);
      Track3D_var t2 = t3dh->create_object (ca);
      t1->w(12);// setting of a pure local attribute
      t1->set_x(1000.0);// some DLRL attributes settings
      t1->set_y(2000.0);
      t1->set_a_radar(r1);// modifies r1->tracks accordingly
      t2->set_x(1000.0);
      t2->set_y(2000.0);
      t2->set_z(3000.0);
      t2->set_a_radar(r1);// modifies r1->tracks accordingly
      ca->write();// all modifications are published
  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Various typos in section 3.1.6.3.7, ObjectHome

  • Key: INBOX-208
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem 1:
    In the table on page 3-26 and 3-27 regarding the ObjectHome entity some types of attributes, parameters and return types are incorrectly shown. In the rest of the document whenever an operation is to have a return type/parameter of a specialized class or an attribute is of a specialized class it does not state the class (for example ObjectRoot) but states the word Undefined between < and > appended with the word if the type (Selection, StrMap, etc, making <undefined>Selection. This is missing various times in the table in section 3.1.6.3.7 regarding the ObjectHome. Specifically for the attributes 'selections' and listener' and for the operations attach_listener (listener param), detach_listener (listener param), create_selection (return type), delete_selection (a_selection param), create_object (return type), create_unregister_object (return type), register_object (unregister_object param), find_object (return type), get_objects(return type), get_created_objects (return type), get_modified_objects (return type), get_deleted_objects (return type).

    Problem 2:
    The attribute 'listener' in the table, should be 'listeners' as used everywhere else in the ObjectHome defintion (see figure 3-4 on page 3-16 and the description for the attribute on page 3-28)

    Problem 3:
    The attribute 'class_name' in the table should be 'name' to be made consistent with figure 3-4 on page 3-16. It should also be updated in the description on page 3-27

    Problem 4:
    The attribute parent (type: ObjectHome) and children (type: ObjectHome[]) should be added to the table. Their descriptions should also be added in the attribute listing directly following the table. (see figure 3-4 where they are mentioned)

    Solution:
    XXX TBD

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Add an operation to the Cache

  • Key: INBOX-154
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    Currently when an application is interested in the creation/modification/deletion of specific objects, he can attach a Listener to the corresponding ObjectHome. We will then get separate callbacks for each object of this type that gets created/deleted/modified. But maybe the user doesn't want all these separate callbacks and just wants to deal with a subset of all possible events (for example only creations). He could do so by not attaching ObjectListeners to the ObjectHomes, but by using the CacheListener and then iterate through all Homes using for example only the get_created_objects. It would be nice if the Cache could then return a list of Homes that contain information that needs to be processed, to prevent the user from also having to iterate through all homes that have nothing to report.

    Solution:

    Add an operation to the Cache that returns a list of indexes for all homes that received updates in the current update round.

    Section 3.1.6.2, Figure 3-4: Add an operation to the Cache called "get_updated_home_indexes".

    Section 3.1.6.3.9: Add the following entry to the table:

    Cache
    operations
    get_updated_home_indexes integer[]

    Section 3.1.6.3.4
    Add:

    · retrieve the indexes of all ObjectHomes that received updates in the current update round (get_updated_home_indexes).

    Section 3.2.1.2: Add to the IDL of the Cache interface the following line:

    LongSeq get_updated_home_indexes( );

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

set_auto_deref, deref_all, underef_all operations

  • Key: INBOX-204
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The descriptions of the deref_all, underef_all and set_auto_deref should be stated to be implementation dependant, as these operations basically are only a standardized set of operations which can be used by DLRL applications to optimize the memory usage of the underlying DLRL implementation, but the exact affects and such are impossible to describe on specification level. And whether it is more efficient for an implementation to always load the states or do it on request basis is an implementation issue, so we would like to state for the mentioned three operation that the affects are implementation dependant.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Support local class in Mapping XML

  • Key: INBOX-213
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Currently the Mapping tags do not give any support for local classes, they mention local attributes but ignore locally defined valuetypes in the DLRL IDL, in default mapping these valuetypes would always lead to DCPS topics being generated from them.

    Solution:
    Make the local element a sub-tag of the dlrl tag as well. If the local tag is defined as sub-tag of the dlrl element, then the name should be fully qualified and refer to a class being 'local', if the local tag is a sub-tag of the classMapping element then it means the attribute is local and the name does not have to be fully qualified.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

set_query and set_parameters operation

  • Key: INBOX-161
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The set_query and set_parameters operation both have a return value of type boolean indicating success or not and an exception which is raised if an error was detected. Obviously one of the two is not neccesary, if an exception is raised then the return value is irrelevant and vice versa. So a choice needs to be made for one or the other. We propose to keep the exception as that is in line with other similar operation (set_content_filter on the ObjectHome for example). Also update the IDL description on page 3-52 in section 3.2.1.2.

    Solution:
    Change the return value of the set_query and set_parameter operations from boolean to void. And replace the following text:
    o set the value of the expression and its parameters (set_query); a TRUE return value indicates that they have been successfully changed.
    o set the values of the parameters (set_parameters). The number of parameters must fit with the values required by the expression. A TRUE return value indicates that they have been successfully changed.

    With:
    o set the value of the expression and its parameters (set_query). If the expression is not valid or if it's parameters do not match the number of parameters in the expression then a SQLError is raised.
    o set the values of the parameters (set_parameters). The number of parameters must fit with the values required by the expression, else a SQLError is raised.

    On page 3-52 in section 3.2.1.2 IDL description replace:
    boolean set_query (
    in string expression,
    in StringSeq parameters) raises (SQLError);
    boolean set_parameters ( in StringSeq parameters ) raises (SQLError);
    With:
    void set_query (in string expression, in StringSeq parameters) raises (SQLError);
    void set_parameters ( in StringSeq parameters ) raises (SQLError);

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Let the attach/detach listener operation return a boolean

  • Key: INBOX-220
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Change the return type of the attach_listener and detach_listener operation on the Cache entity to return a boolean instead of void. True indicates the operation was successfully (i.e. the listener was successfully attached or successfully removed). False indicates the operation was not successfully (i.e. the listener could not be attached, because it already was attached for the attach operation and for the detach operation it means the listener could not be detached because it was not attached in the first place.

    Solution:
    On page 3-22 in the table for section 3.1.6.3.4 replace:
    attach_listener void
    listener CacheListener
    detach _listener void
    listener CacheListener

    With:
    attach_listener boolean
    listener CacheListener
    detach _listener boolean
    listener CacheListener

    On page 3-23 for the description of the attach/detach listener add a sentence indicating the boolean return value and its meaning
    Replace:
    · attach/detach a CacheListener (attach_listener, detach_listener).

    With:
    · attach/detach a CacheListener, if the operation was successful true is returned and false if otherwise (attach_listener, detach_listener).

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Add exceptions, clarify usage of other exceptions

  • Key: INBOX-151
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    Several new Exceptions need to be introduced in the exception list on page 3-18:
    · BadParameter - To be thrown when an illegal parameter is used for an operation. An illegal parameter is defined as a NIL pointer
    · TimeOut - To be thrown during the write operation of the CacheAccess to indicate a time out occurred while trying to write the contents of the CacheAccess.

    On page 3-48 in section 3.2.1.2 IDL description the exception list should be expanded to include the following two definitions:
    exception BadParameter

    {string message;};
    exception TimeOut {string message;}

    ;

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Change description on mapping rules for Exceptions or return values

  • Key: INBOX-194
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    Section 3.2.1.1 Change description on mapping rules for Exceptions or return values. Currently it states that return-values are used for recoverable errors and exceptions for non-recoverable errors. Remove this description: exceptions are used for both cases.

    Solution:

    TBD.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Section 3.1.3.1 on page 3-3

  • Key: INBOX-132
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Section 3.1.3.1 on page 3-3 states that a simple type may be a 'simple structure', a footnote explains that a simple structure may be a structure that can be mapped inside one DCPS data. But this is still very unclear, we would like to clarify what a simple structure is by changing the footnote to state:
    "A simple structure is a structure that only contains members of simple type"
    This must also be changed on page 3-5, the last line on the page.

    Furthermore the union type should also be added to the list of simple types on page 3-3.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of Fully qualified names in the model tags in section 3.2.2.3

  • Key: INBOX-203
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    The XML as described in section 3.2.2.3 and sub section has a problem in relation to IDL modules. How to represent to valuetypes named Foo which are defined in different modules for example? It is currently not clear how this should be done. It is our suggestion to clarify that fully qualified names should be used in IDL sense. Where a valuetype Foo in module Test would be referred to as "Test::Foo". The subsections of section 3.2.2.3 should state for each element attribute if fully qualified names must be used.

    Solution:

    In section 3.2.2.3 replace:
    Model tags are specified by means of XML declarations that must be compliant with the DTD listed in the following section; subsequent sections give details on the constructs.
    With:
    Model tags are specified by means of XML declarations that must be compliant with the DTD listed in the following section; subsequent sections give details on the constructs. The elements in the DTD often have attributes which give the name of IDL defined entities. To correctly identify such entities, fully qualified names (in IDL sense) should be used as much as possible. For example a valuetype Foo in module Test would be referred to as "Test::Foo".

    In section 3.2.2.3.2.2 EnumDef replace:
    This tag contains an attribute name (scoped name of the IDL enumeration) and as many value sub-tags that needed to give values.
    With:
    This tag contains an attribute name (fully qualified name of the IDL enumeration) and as many value sub-tags that needed to give values.

    In section 3.2.2.3.2.3 TemplateDef replace:
    This tag contains three attributes:
    o name - gives the scoped name of the type.
    o pattern - gives the construct pattern. The supported constructs are: List, StrMap, IntMap, and Set.
    o itemType - gives the type of each element in the collection.

    With:
    This tag contains three attributes:
    o name - gives the fully qualified name of the type.
    o pattern - gives the construct pattern. The supported constructs are: List, StrMap, IntMap, and Set.
    o itemType - gives the fully qualified type name of each element in the collection.

    In section 3.2.2.3.2.4 AssociationDef replace:
    o class - contains the scoped name of the class.
    With:
    o class - contains the fully qualified name of the class.

    In section 3.2.2.3.2.5 compoRelationDef replace:
    o class - contains the scoped name of the class.
    With:
    o class - contains the fully qualified name of the class.

    In section 3.2.2.3.2.6 ClassMapping replace:
    This tag contains one attribute name that gives the scoped name of the class and:
    With:
    This tag contains one attribute name that gives the fully qualified name of the class and:

    In section 3.2.2.3.2.7 MainTopic replace:
    This tag gives the main DCPS Topic, to which that class refers. The main Topic is the topic that gives the existence of a object (an object is declared as existing if, and only if, there is an instance in that Topic matching its key value.
    It comprises one attribute (name) that gives the name of the Topic, one (optional) attribute (typename) that gives the name of the type (if this attribute is not supplied the type name is considered to be equal to the topic name) and:
    With:
    This tag gives the main DCPS Topic, to which that class refer. The main Topic is the topic that gives the existence of an object (an object is declared as existing if, and only if, there is an instance in that Topic matching its key value).
    It comprises one attribute (name) that gives the name of the Topic (must adhere to topic naming rules, see section B-3 regarding the TOPICNAME), one (optional) attribute (typename) that gives the fully qualified name of the type (if this attribute is not supplied the type name is considered to be equal to the topic name) and:

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exceptions/usage for remove operation on List in section 3.1.6.3.16

  • Key: INBOX-218
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The remove operation should do nothing if it did not contain an element with the specified key.

    The remove operation on the collection (list, strmap, intmap, but NOT set) should mention it raises a PreconditionNotMet if:

    • The owner ObjectRoot of the List is not contained within a (writeable) CacheAccess
    • The owner ObjectRoot has not yet been registered (i.e. has no identity)

    This should also be fixed in the IDL descriptions (normal and implied)

    In section 3.2.1.2 IDL description: For the List replace:
    void remove( ) ;
    With:
    void remove( ) raises (PreconditionNotMet);;

    For the StrMap valuetype:
    Replace:
    void remove( in string key );
    With:
    void remove( in string key ) raises (PreconditionNotMet);

    For the IntMap valuetype:
    Replace:
    void remove( in long key );
    With:
    void remove( in long key ) raises (PreconditionNotMet);

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify typical scenario for read mode of a CacheAccess in section 3.1.6.5.

  • Key: INBOX-157
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.5.1 it states the typical scenario for a cache access in read mode. But it would be nice if it was expand with a step between 4 and 5 which states that if desired new contracts can be created, existing contracts can be modified or deleted and step 3 can be repeated.

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Description not detailed enough

  • Key: INBOX-222
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The description of the getter, setter and is_xxx_modified operation for attributes of a DLRL object is not detailed enough. An exception listing should be added, and for what type of attributes the exception is valid and under which circumstances.

    Exceptions for get_<attribute_name> operations:
    · DCPSError (which should be made a 'runtime' exception, to prevent nasty catch clause needed for each getter!!)
    o For all (shared) attributes:
    § a DCPSError if some error happened in DCPS (state might need to be fetched from DCPS, if the object was not dereffed).

    · NotFound
    o For mono relation shared attributes:
    § A NotFound exception if the related attribute could not be located.

    Exceptions for set_<attribute_name> operations:
    · PreconditionNotMet
    o For all (shared) attributes:
    § Object is not in a (writeable) cacheaccess
    o For any (shared) attribute that is a key field (predefined mapping only)
    § Object is already registered (i.e. identity may not be registered anymore)
    o For mono relation shared attributes:
    § If the value of the parameter is NIL, but the relation was modeled as a mandatory relation (see XXX)
    § If the object in the parameter has different keys then the owner object and the relation is mapped using so called 'shared' keys.
    o For mono/multi relation shared attributes:
    § 'Owning' object (or owner of the collection if multi relation) is not yet registered.
    § 'Target' object (or owner of the collection if multi relation) is not yet registered.
    § If the object (or owner of the collection if multi relation) represented by the parameter has already been deleted (this does not include marked for destruction!)
    § If the object (or owner of the collection if multi relation) in the parameter is not defined in the scope of the same CacheAccess
    o For multi relation shared attributes:
    § If the parameter value is NIL

    Furthermore the descriptions should also be augmented. The setter description should state that a setter for a collection type basically clears the entire contents of the collection of the 'owner' objects and then copies in the content of the collection in the parameter. Making the setter for a collection work like a clear of the contents of the 'old' collection and then an element for element add of the elements of the other collection.

    The is_xxx_modified operation description should also state that it takes a ReferenceScope as parameter for (mono/multi) relations. SIMPLE_CONTENT_SCOPE only takes the reference to the related object into account (for multi relations this means elements in the collection, not the multi relation object (pointer) itself which should never change during the life cycle of the owning object!) and REFERENCED_CONTENTS_SCOPE takes the reference to the related object into account as well as the content of the object.

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of the is_modified() operation on the ObjectRoot

  • Key: INBOX-173
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Firstly all references to primary and secondary (or clone) objects should be replaced with cache and cacheaccess objects respectively. Furthermore the usage of the is_modified operation is unclear, it states that it returns false when the read_state is new. Suppossedly because nothing is modified (it's the first time the data is seen). In that light we can only wonder what the is_modified should return when the DLRL receives a new sample for the underlying topics of the Object, but all the attributes have the exact same value (although the real compare is more complex, as some attributes are actually foreign keys and if a new generation of a relation appeared then the attribute value may not have changed, but the relation represented by the attribute has… but that's more of an implementation issue I suppose), or when a dispose is received, but no new data sample. In those cases should this operation return false, or true? That's not clear from the current description of the operation.
    Basically we see two options for the is_modified operation
    1) true is only returned when one of the is_xxx_modified operations returns true
    2) true is only returned if the read_state of the object is something else then NOT_MODIFIED
    The first operation has some added value, as an application now does not need to access each is_xxx_modified operation and find out nothing has changed. However the drawback is that the read_state may be MODIFIED or DELETED, but the is_modified operation still indicates nothing has changed. Forcing an application to always use the read_state() operation along with the is_modified operation and never being able to just use one or the other to determine if something changed at the object (because an object becoming new or disposed is ussually something an application desires to know). This approach also makes the is_modified operation rather complex, as it's implementation has to evaluate each mono attribute by value, each relation by value AND by reference (by value is needed if it was NotFound before and after an update round, and by reference is needed in case of new generations). This all makes the is_modified operation from a seemingly light weight operation into a heavy weight one.
    Furthermore if we look at the added benefit of the is_modified operation, it's that we can provide a scope, asking it to check out it's related/contained objects as well for modifications. To us that's the real advantage of this operation over simply getting the read_state of the operation.
    And that's why we prefer option 2, only returning true if the read_state() is something else then NOT_MODIFIED. Because then an application can simply use the is_modified operation to determine what it wants to do with the object, whether it's new, deleted, modified or one of it's related objects has something modified. That does not matter, one call will tell the application whatever it needs to know, if the application does not require modification info on related objects, then it can just use the read_state or the is_modified with a simple_object_scope.

    Solution:
    Replace:
    o see if the object has been modified by incoming modifications (is_modified). is_modified takes as parameter the scope of the request (i.e., only the object contents, the object and its component objects, the object and all its related objects). In case the object is newly created, this operation returns FALSE; 'incoming modifications' should be understood differently for a primary object and for a clone object.
    o For a primary object, they refer to incoming updates (i.e., coming from the infrastructure).
    o For a secondary object (cloned), they refer to the modifications applied to the object by the last CacheAccess::refresh operation.

    With:
    o see if the object has been updated in the current update round (is_modified). is_modified takes as parameter the scope of the request, i.e.,only the object contents (SIMPLE_OBJECT_SCOPE), the object contents and its composed objects contents (CONTAINED_OBJECTS_SCOPE, unlimited depth), the object contents, its composed objects contents and all its related (non-composed) objects contents (RELATED_OBJECTS_SCOPE, depth of 1 for related objects and unlimited depth for contained objects). Incoming modifications should be understood differently for a cache object and for a cacheaccess object.
    o For a cache object, they refer to incoming updates (i.e., coming from the infrastructure).
    o For a cacheaccess object that is cloned from a cache objects, they refer to the modifications applied to the object by the last CacheAccess::refresh operation.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

In section 3.1.6.3.6 regarding the Contract clarify some things

  • Key: INBOX-190
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem (1/4) (typo):
    Each attribute and operation description wrongly starts with a quotation mark, these should be removed.
    Problem (2/4) (typo):
    The description of attribute depth talks about a RELATED_OBJECT_SCOPE. This should be RELATED_OBJECTS_SCOPE (objects should thus be plural).
    Problem (3/4) (clarification):
    During the description of the scope attribute the various scopes are explained, for clarification purposes insert the type of scope right after the explaination.
    Problem (4/4) (clarification):
    In the description for the set_depth operation, indicate that the depth is ignored unless the scope is set to RELATED_OBJECTS_SCOPE, just like it says at the getter for the depth attribute.

    Solution:

    Replace:
    o "The top-level object (contracted_object). This is the object that acts as the starting point for the cloning contract.
    o "The scope of the cloning request (i.e., the object itself, or the object with all its (nested) compositions, or the object with all its (nested) compositions and all the objects that are navigable from it up till the specified depth).
    o "The depth of the cloning contract. This defines how many levels of relationships will be covered by the contract (UNLIMITED_RELATED_OBJECTS when all navigable objects must be cloned recursively). The depth only applies to a RELATED_OBJECT_SCOPE.

    It offers methods to:
    o "Change the depth of an existing contract (set_depth). This change will only be taken into account at the next refresh of the CacheAccess.
    o "Change the scope of an existing contract (set_scope). This change will only be taken into account at the next refresh of the CacheAccess.

    With:
    o The top-level object (contracted_object). This is the object that acts as the starting point for the cloning contract.
    o The scope of the cloning request (i.e., the object itself (SIMPLE_OBJECT_SCOPE), or the object itself along with all its (nested) compositions (CONTAINED_OBJECTS_SCOPE), or the object itself along with all its (nested) compositions and all the objects that are navigable from it up till the specified depth (RELATED_OBJECTS_SCOPE)).
    o The depth of the cloning contract. This defines how many levels of relationships will be covered by the contract (UNLIMITED_RELATED_OBJECTS when all navigable objects must be cloned recursively). The depth only applies to a RELATED_OBJECTS_SCOPE.

    It offers methods to:
    o Change the depth of an existing contract (set_depth). This change will only be taken into account at the next refresh of the CacheAccess. The depth only applies to a RELATED_OBJECTS_SCOPE.
    o Change the scope of an existing contract (set_scope). This change will only be taken into account at the next refresh of the CacheAccess.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Rewrite sentence on page 3-1, section 3.1

  • Key: INBOX-212
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    DLRL is unmistakenly linked with DCPS. DLRL requires DCPS entities to create a cache for example, and one can directly request the publisher or subsriber from such a Cache. A DLRL not built on top of DCPS is not a DLRL at all.

    Solution:
    Replace:
    It is an optional layer that may be built on top of the DCPS layer.

    With:
    It is an optional layer that is built on top of the DCPS layer.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify what happens in the purge operation of the CacheAccess

  • Key: INBOX-171
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The purge operation needs to be further detailed as what the consequences of the operation are. Also the wrong quotation mark at the end of the description needs to be removed as well.

    Solution:

    Replace:
    Detach all contracts (including the contracted DLRL Objects themselves) from the
    CacheAccess (purge)."

    With:
    Detach all Contracts (including the contracted ObjectRoots themselves) from the
    CacheAccess (purge). If the CacheAccess is writeable then the CacheAccess will unregister itself for each purged (previously written) ObjectRoot. If the CacheAccess was the last writeable CacheAccess within the scope of the owning Cache for the purged (previously written) ObjectRoot, then an explicit unregister_instance is performed for that instance at the respective DataWriter entity. A DCPSError is raised if the purge failed due to an error on DCPS level.

    In section 3.2.1.2 on page 3-57 IDL description regarding the CacheAccess interface replace:
    void purge ();
    With:
    void purge () raises (DCPSError);

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Which exceptions can be raised under which circumstances?

  • Key: INBOX-187
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The description of the write operation does not specify which exceptions can be thrown. Not that the IDL description on page 3-57 also states the ReadOnlyMode exception can be raised, but that exception no longer exists! So fix this as well. See issue XXX and XXX for mention of the TimeOut and InvalidObjects exceptions.

    Solution:

    Replace:
    o Write objects (write). If the CacheAccess::cache_usage allows write operation, those objects can be modified and/or new objects created for that access and eventually all the performed modifications written for publications.

    With:
    o Write objects (write). If the CacheAccess::cache_usage allows write operation, those objects can be modified and/or new objects created for that access and eventually all the performed modifications written for publications. A PreconditionNotMet is raised if the CacheAccess::cache_usage does not allow the write operation (i.e. usage is READ_ONLY). A TimeOut exception is raised if one of the underlying DCPS DataWriter entities timed out. A DCPSError is raised if the write failed due to an error in the DCPS layer.

    In section 3.2.1.2 on page 3-57 regarding the IDL description of the write() operation of the interface CacheAccess replace:
    void write ()
    raises (
    ReadOnlyMode,
    DCPSError);
    With:
    void write () raises (DCPSError, PreconditionNotMet, InvalidObjects, TimeOut);

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of refresh operation on the CacheBase, section 3.1.6.3.2

  • Key: INBOX-198
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.3.2 in the explantion of the refresh operation it should be stated a DCPSError may be raised if an error occurred while trying to read data from DCPS. And it should be stated a PreconditionNotMet exception is raised in case the cache_usage of the cache base excludes read operations.

    Solution:

    Replace:
    o Refresh the contents of the Cache with respect to its origins (DCPS in case of a main Cache, Cache in case of a CacheAccess).

    With:
    o Refresh the contents of the CacheBase with respect to its origins (DCPS in case of a main Cache, Cache in case of a CacheAccess). A PreconditionNotMet is raised if the cache_usage excludes read operations.
    A DCPSError is raised if an error occurred while trying to read data from DCPS. If the CacheBase represents a Cache that has updates_enabled set to true, then this operation is considered a no-op.

    In section 2.2.1.2 IDL Description on page 3-57 regarding the definition of the local interface CacheBase replace:
    void refresh( ) raises (DCPSError);
    With:
    void refresh( ) raises (DCPSError, PreconditionNotMet);

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Error in the ownership of a SelectionCriterion

  • Key: INBOX-116
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The spec says that the Selection takes ownership of the SelectionCriterion parameter passed in create_selection (see 3.1.6.3.7, ObjectHome, create_selection bullet item).

    However, this violates CORBA "in" parameter passing semantics, in which the client owns an "in" parameter and is responsible for it.

    The right way (in CORBA terms) to do this is for the client to create the FooSelectionCriterion on the heap, store it in a FooSelectionCriterion_var smart pointer, and let the smart pointer release it when it goes out of scope. The Selection can make a "copy" of the FooSelectionCriterion, presumably by bumping up its reference count.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Request clarification on the behavior of is_modified

  • Key: INBOX-117
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The spec implies that is_modified is only valid in the context of a listener callback (I suppose that would be an ObjectListener or a SelectionListener callback). See section 3.1.6.4.1, general scenario, which says that after end_updates is called, the "modification states of the updated objects is cleaned". Does that mean that, outside of an ObjectListener or SelectionListsner, a call to is_modified always returns false?

    Also, the spec is not clear about what happens in a CacheAccess. A CacheAccess, of course, has no listeners. So, for the is_modified() methods to be useful from a CacheAccess, they'd have to be valid from outside of a listener for an object in a CacheAccess. Is that the case?

    There is also the corner case of a manual Selection. A manual Selection might not have a listener. There wouldn't be any way to call is_modified () on an object in a manual Selection that doesn't have a Listener – you'd have to attach a Listener to the manual selection, and call is_modified in the callback that happens when you call refresh().
    Is that what the spec intends?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Int the future, allow DLRL valuetype implementations?

  • Key: INBOX-122
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The DLRL spec uses CORBA valuetypes to specify DLRL objects. The implementations of these CORBA valuetypes (e.g. Foo) are completely provided by the DLRL – the user doesn't have to implement anything, which is great from a simplicity standpoint.

    However, this limits the DLRL valuetypes to being not much more that fancy structs with inheritance and relationships, but no behavior.

    One of the capabilities of standard CORBA valuetypes is the ability to specify valuetype operations in IDL and then implement them in the target language. The CORBA valuetype specification has permits the user to write the valuetype's implementation class, providing behavior for the methods specified in IDL. The user then implements a valuetype factory as a hook to create instances of the user-written valuetype implementation.

    I can see a similar comcept as useful to DLRL. It would probably be useful for a user to specify valuetype operations in DLRL IDL and implement them in the target language.
    One way to do this is to have the DLRL compiler generate a Foo class with a pure virtual method for each valuetype operation. The user inherits from it, implementing a MyFoo with implemntations of the pure virtual methods.

    We also need a factory; naturally, we'd use the FooHome. The generated FooHome would include a pure virtual "create()", or something like it, which the user would implement in a derived MyFooHome class to create instances of his MyFoo. Instead of creating a FooHome and registering it with the Cache, the user creates a MyFooHome and registers it with the Cache. The DLRL core uses the MyFooHome's overridden create() method to make new Foo handles (which are actually MyFoo handles, containing the user's behavior).

    There may be holes in this, but the basic idea is probably useful. It would permit a DLRL object model to be a full object model.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Section: 3.1.4.5

  • Key: INBOX-131
  • Status: pending  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "However an exiting DCPS model by construction is unlikely to rely heavily on inheritance between its ‘classes.’" You mean "existing".

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DDS DLRL Issue: Clarify behavior of a Composition

  • Key: INBOX-110
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    Add a new subsection:

    8.1.3.2.3 Compositions

    o A composition implies cascading deletion. When the owning object is deleted, the composed (i.e. owned) object is also deleted. When the owning object is deleted, its composed objects must also be present in the same CacheAccess so they too can be deleted. Failure to do this will result in a PreconditionNotMet exception on the ObjectRoot::destroy() call.

    o A composed (i.e. owned) object may only have one owner. Any attempt to set an owned ObjectRoot on two different owning object will result in a PreconditionNotMet exception

    Modify 8.1.6.3.14 ObjectRoot, by adding to the descriptions of the relevant operations:

    destroy: If the object has composition relations, all composed objects must be present in the CacheAccess. Otherwise, a PreconditionNotMet is thrown.

    set_attribute: If the attribute is a composition relation, the composed object must not be owned by any other object. Otherwise, a PreconditionNotMet is thrown.

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

A descriptive name

  • Key: INBOX-231
  • Status: pending  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The following IDs can be used in PT issue IDs:
    TYPO = To reflect the issue is about a type in the specification
    CLAR = To reflect the issue clarifies something in the specification
    ARCH = To reflect the issue highlights an architectural significant problem in the specification.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Figure 3-4 on page 3-16 is missing some operations in some classes

  • Key: INBOX-192
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The find_object operation is not listed in the ObjectHome class in figure 3-4 on page 3-16.

    Solution:
    Obvious

  • Reported: DDS 1.2 — Thu, 15 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

section 3.2.2.3.2.10 MonoAttribute, 3.2.2.3.2.12 MonoRelation

  • Key: INBOX-181
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.2.3.2.10 MonoAttribute, 3.2.2.3.2.12 MonoRelation the cases for the content attributes values of the keyDescription is incorrect

    Solution:
    In section 3.2.2.3.2.10 on page 3-67 replace:
    <monoAttribute name="y">
    <placeTopic name="Y_TOPIC">
    <keyDescription content="SimpleOID">
    <keyField>OID</keyField>
    </keyDescription>
    </placeTopic>
    <valueField>Y</valueField>
    </monoAttribute>
    With:
    <monoAttribute name="y">
    <placeTopic name="Y_TOPIC">
    <keyDescription content="SimpleOid">
    <keyField>OID</keyField>
    </keyDescription>
    </placeTopic>
    <valueField>Y</valueField>
    </monoAttribute>

    In section 3.2.2.3.2.12 on page 3-68 replace:
    <monoRelation name="a_radar">
    <keyDescription content="SimpleOID">
    <keyField>RADAR_OID</keyField>
    </keyDescription>
    </monoRelation>
    With:
    <monoRelation name="a_radar">
    <keyDescription content="SimpleOid">
    <keyField>RADAR_OID</keyField>
    </keyDescription>
    </monoRelation>

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

In section 3.2.2.3.2.11 MultiAttribute, the example xml code

  • Key: INBOX-168
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The example XML code forgets to properly fill out the multiPlaceTopic, forgetting to list the index attribute of the multiPlaceTopic. Also the content attribute of the keyDescription has an incorrect value. It should be FullOid, not FullOID (cases).

    Solution:

    Replace:
    <multiAttribute name="comments">
    <multiPlaceTopic name="COMMENTS-TOPIC"
    <keyDescription content="FullOID">
    <keyField>CLASS</keyField>
    <keyField>OID</keyField>
    </keyDescription>
    </multiPlaceTopic>
    <valueField>COMMENT</valueField>
    </multiAttribute>
    With:
    <multiAttribute name="comments">
    <multiPlaceTopic name="COMMENTS-TOPIC" indexField="INDEX">
    <keyDescription content="FullOid">
    <keyField>CLASS</keyField>
    <keyField>OID</keyField>
    </keyDescription>
    </multiPlaceTopic>
    <valueField>COMMENT</valueField>
    </multiAttribute>

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

section 3.2.1.2.2 Implied IDL

  • Key: INBOX-223
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.1.2.2 Implied IDL, typo in the FooHome defintion for the create_selection operation. The parameters listed are incorrect. They should be DDS::SelectionCriterion criterion instead of FooFilter filter. And the concerns_contained_objects attribute is missing all together. Furthermore the raises clause is wrong as well, the BadParameter exception did not exist in that definition of the specification, it should be PreconditionNotMet.

    Solution:
    Replace:
    FooSelection create_selection (
    in FooFilter filter,
    in boolean auto_refresh)
    raises (DDS::BadParameter);
    With:
    FooSelection create_selection (in DDS::SelectionCriterion criterion, in boolean auto_refresh, in boolean concerns_contained_objects) raises (DDS::PreconditionNotMet);

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Typos in section 3.2.1.2 IDL description

  • Key: INBOX-195
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.1.2 IDL description on page 3-49 for the definition of the SelectionListener the on_object_out operation is listed, however this operation is generated on the derived class 'Foo', thus should be contained within the comments just like operations on_object_modified and on_object_in. This was not correctly revised during the last spec revision.

    Solution:
    Replace:
    local interface SelectionListener

    { /* Will be generated with the proper Foo type * in the derived FooSelectionListener * void on_object_in ( in ObjectRoot the_object); void on_object_modified ( in ObjectRoot the_object); * ***/ void on_object_out ( in ObjectRoot the_object); }

    ;

    With:
    local interface SelectionListener

    { /* Will be generated with the proper Foo type in the derived FooSelectionListener * * void on_object_in (in ObjectRoot the_object); * void on_object_modified (in ObjectRoot the_object); * void on_object_out (in ObjectRoot the_object); */ }

    ;

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Typos in section 3.1.6.4.1

  • Key: INBOX-134
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Section 3.1.6.4.1 still talks about operations that no longer exist (how_many_added, how_many_removed, etc). In the second bullet these operations are mentioned. It is our suggestion to remove the mention of those operations, and simply state that there are operations to retrieve precisely which parts of the object has been modified, but don't mention explicitly which operations are available for this purpose.

    Solution:
    Replace:
    o Then all the updates are actually applied in the cache16. When an object is modified, several operations allow to get more precisely which parts of the object are concerned (see ObjectRoot::is_modified operations as well as the operations for Collection, namely, is_modified, how_many_added, how_many_removed, removed_values, and which_added); these operations can be called in the listeners.
    With:
    o Then all the updates are actually applied in the cache16. When an object is modified, several operations allow to get more precisely which parts of the object are concerned, such operations can be called in the listeners.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

which_contained_modified operation should be removed

  • Key: INBOX-217
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The which_contained_modified operation should be removed from the table on page 3-33 as well as from the text description on page 3-35, as the operation no longer exists (see figure 3-4). Getting the modified elements from collections can be done through the relevant collection interface operation (added_elements, modified_elements and removed_elements). In the IDL description in section 3.2.1.2 on page 3-50 the enum RelationKind, valuetype RelationDescription and it's derived valuetypes ListRelationDescription, IntMapRelationDescription and StrMapRelationDescription as well as the sequence typedef for RelationDescriptions should be removed.

    Solution:
    Remove the which_contained_modified operation from the table and remove the following text (at the top of page 3-35)
    o get which contained objects have been modified (which_contained_modified). This method returns a list of descriptions for the relations that point to the modified objects (each description includes the name of the relation and if appropriate the index or key that corresponds to the modified contained object).

    On page 3-50 in section 3.2.1.2 remove the following:
    enum RelationKind

    { REF_RELATION, LIST_RELATION, INT_MAP_RELATION, STR_MAP_RELATION}

    ;
    valuetype RelationDescription

    { public RelationKind kind; public RelationName name; }

    ;
    valuetype ListRelationDescription : RelationDescription

    { public long index; }

    ;
    valuetype IntMapRelationDescription : RelationDescription

    { public long key; }

    ;
    valuetype StrMapRelationDescription : RelationDescription

    { public string key; }

    ;
    typedef sequence<RelationDescription> RelationDescriptionSeq;

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Minor typo's and inconsistencies

  • Key: INBOX-136
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Remove quotations in the table contained in the Contents chapter (page 3-1).

    Solution:

    Replace:
    Section Title Page
    "Platform Independent Model (PIM)" 3-1
    "OMG IDL Platform Specific Model (PSM)" 3-45

    With:
    Section Title Page
    Platform Independent Model (PIM) 3-1
    OMG IDL Platform Specific Model (PSM) 3-45

    Problem:
    Footnote 2 is on wrong page.

    Solution:
    Move footnote 2 from page 3-3 to page 3-2

    Problem:
    In section 3.1.3.3, paragraph two, last sentence says 'They appear in grey on the schema.' Referring to the next figure, but no objects are in grey on that figure.

    Solution:
    Remove the sentence 'They appear in grey on the schema.' So that the paragraph looks as follows.

    Replace:
    Note that two objects that will be part of a DLRL model (namely ObjectRoot that is the
    root for all the DLRL classes as well as ObjectHome that is the class responsible for
    creating and managing all DLRL objects of a given class) are featured to show the
    conceptual relations between the metamodel and the model. They appear in grey on the
    schema.

    With:
    Note that two objects that will be part of a DLRL model (namely ObjectRoot that is the
    root for all the DLRL classes as well as ObjectHome that is the class responsible for
    creating and managing all DLRL objects of a given class) are featured to show the
    conceptual relations between the metamodel and the model.

    Problem:
    The first sentence of section 3.1.5.1 should not say:
    A DLRL class is associated with several DCPS Topic
    But say
    A DLRL class is associated with several DCPS Topics
    IE topics should be made plural.

    Solution:
    Replace:
    A DLRL class is associated with several DCPS Topic
    With:
    A DLRL class is associated with several DCPS Topics

    Problem:
    In figure 3-4 the CacheFactory shows an operation called 'find_cache', which should be 'find_cache_by_name'. The ObjectHome shows an operation called 'get_new_objects' which should be 'get_created_objects'

    Solution:
    Change operation name 'find_cache' in the CacheFactory class into 'find_cache_by_name'.
    Change operation name 'get_new_objects' in the ObjectHome class into 'get_created_objects'.

    Problem:
    In the table in section 3.1.6.2 in the row regarding the Cache two typos need to be corrected regarding the location of the word 'first' in the sentence regarding attaching objects to the CacheAccess and the last bullet needs to be rewritten and be made more clear.

    Solution:
    Replace:
    Class whose instance represents a set of objects that are locally available. Objects within a Cache can be read directly; however to be modified, they need to be attached first to a CacheAccess. Several Cache objects may be created but in this case, they must be fully isolated:
    o A Publisher can only be attached to one Cache.
    o A Subscriber can only be attached to one Cache.
    o Only DLRL objects belonging to one Cache can be put in relation.

    With:

    Class whose instance represents a set of objects that are locally available. Objects within a Cache can be read directly; however to be modified, they first need to be attached to a CacheAccess. Several Cache objects may be created but in this case, they must be fully isolated:
    o A Publisher can only be attached to one Cache.
    o A Subscriber can only be attached to one Cache.
    o A DLRL object can only have relationships with DLRL objects in the same Cache.

    Problem:
    The table in section 3.1.6.2 in the row regarding the ObjectListener talks about a 'peculiar' ObjectHome. This should say 'particuliar'.

    Solution:
    Replace:
    Interface to be implemented by the application to be made aware of incoming updates on the objects belonging to one peculiar ObjectHome.
    With:
    Interface to be implemented by the application to be made aware of incoming updates on the objects belonging to one particuliar ObjectHome.

    Problem:
    On page 3-18 remove wrong quotation marks and the word identify in the explanation of the AlreadyExisting exception should be identity.

    Replace:
    o "DCPSError: if an unexpected error occured in the DCPS
    o "BadHomeDefinition: if a registered ObjectHome has dependencies to other, unregistered ObjectHomes.
    o "NotFound: if a reference is encountered to an object that has not (yet) been received by the DCPS.
    o "AlreadyExisting: if a new object is created using an identify that is already in use by another object.
    o "AlreadyDeleted - if an operation is invoked on an object that has already been deleted.
    o "PreconditionNotMet - if a precondition for this operation has not (yet) been met.
    o "NoSuchElement - if an attempt is made to retrieve a non-existing element from a Collection.
    o "SQLError - if an SQL expression has bad syntax, addresses non-existing fields or is not consistent with its parameters.

    With:
    o DCPSError: if an unexpected error occured in the DCPS
    o BadHomeDefinition: if a registered ObjectHome has dependencies to other, unregistered ObjectHomes.
    o NotFound: if a reference is encountered to an object that has not (yet) been received by the DCPS.
    o AlreadyExisting: if a new object is created using an identity that is already in use by another object.
    o AlreadyDeleted - if an operation is invoked on an object that has already been deleted.
    o PreconditionNotMet - if a precondition for this operation has not (yet) been met.
    o NoSuchElement - if an attempt is made to retrieve a non-existing element from a Collection.
    o SQLError - if an SQL expression has bad syntax, addresses non-existing fields or is not consistent with its parameters.

    Problem:
    The first sentence in section 3.1.6.3.2, CacheBase, should talk about Cache-like objects, not Cache objects. Various wrong quotation marks are used in the attribute and operation listings. Attributes and operation names are not in bold at the description as is common throughout the spec. A bullet is missing for the explanation of the kind attribute. A new line is missing before the sentence "It offers methods to:". And the word 'cache' in the explanation of CacheUsage should be CacheBase

    Solution:
    Replace:
    CacheBase is the base class for all Cache classes. It contains the common functionality that supports Cache and CacheAccess.

    With:
    CacheBase is the base class for all Cache-like classes. It contains the common functionality that supports Cache and CacheAccess.

    Replace:
    The public attributes give:
    o "The cache_usage indicates whether the cache is intended to support write operations (WRITE_ONLY or READ_WRITE) or not (READ_ONLY). This attribute is given at creation time and cannot be changed afterwards.
    o "A list of (untyped) objects that are contained in this CacheBase. To obtain objects by type, see the get_objects method in the typed ObjectHome.
    The kind describes whether a CacheBase instance represents a Cache or a CacheAccess.It offers methods to:
    o "Refresh the contents of the Cache with respect to its origins (DCPS in case of a main Cache, Cache in case of a CacheAccess).

    With:
    The public attributes give:
    o The cache_usage indicates whether the CacheBase is intended to support write operations (WRITE_ONLY or READ_WRITE) or not (READ_ONLY). This attribute is given at creation time and cannot be changed afterwards.
    o A list of (untyped) objects that are contained in this CacheBase. If an error in DCPS occurred, a DCPSError is raised. To obtain objects by type, see the get_objects method in the typed ObjectHome.
    o The kind describes whether a CacheBase instance represents a Cache or a CacheAccess.

    It offers methods to:
    o Refresh the contents of the CacheBase (refresh) with respect to its origins (DCPS in case of a main Cache, Cache in case of a CacheAccess).

    Problem:
    Several wrong quotation marks in section 3.1.6.3.3, CacheAccess, can be seen in the description of various operations.

    Solution:

    We propose to remove these quotation marks before operation descriptions of type_names, create_contract and delete_contract

    Problem (1/2):
    On page 3-29 in section 3.1.6.3.8 regarding the ObjectListener it incorrectly states the parameters of the operations as ObjectReference (which doesn't even exist anymore!), ObjectRoot and ObjectRoot. All these return type should be replaced with Undefined as the operations are generated in the typed ObjectListener class as typed operations.

    Solution (1/2):
    Replace the return types of the operation in the table with Undefined.

    Problem (2/2):
    On page 3-30 at the top it states that four operations are following, but only three operations are listed! There are only 3 operations!!

    Solution (2/2):
    Replace:
    It is defined with four methods:
    With:
    It is defined with three methods:

    Problem:
    On page 3-29 in section 3.1.6.3.8 regarding the Selection it incorrectly states the types of the attributes 'members' and listener as ObjectRoot[] and SelectionListener respectivly. This should be replaced by <undefined>[] and <undefined>SelectionListener respectively.
    The operation set_listener also wrongly specifies the return type and parameter type, both should be replaced by <undefined>SelectionListener.

    Solution:
    Obvious.

    Problem:
    In the table on page 3-31 regarding the SelectionCriterion it states the type of attribute kind as 'SelectionCriteria'. However this type does not exist anywhere! It should be CriterionKind. Also the attribute listing underneath the table is not conform the style used throughout the DLRL spec.

    Solution:
    Replace SelectionCriteria with CriterionKind in the table, make the style conform.

    Problem:
    In the table on page 3-32 in section 3.1.6.3.11 about the FilterCriterion is states that parameter 'an_object' has as type 'ObjectRoot' However this should be '<undefined>' as the method is properly generated in the 'FooFilter' class.

    Solution:
    Replace the parameter type of an_object with the word <undefined>.

    Problem:
    In the table on page 3-32 in section 3.1.6.3.12 regarding the QueryCriterion it states that the parameter names for the set_query (second param) and the set_parameters is 'arguments'. This is not consistent with the IDL PSM, which states 'parameters' as name. They should be made the same. The names in the table should be replaced with the name 'parameters'.

    Solution:
    Replace the parameter's name 'arguments' with 'parameters'.

    Problem:
    In section 3.1.6.3.3 CacheAccess, the table states that the operations 'the_object' parameter has as type ObjectRoot. However since these operations are generated in the derived class it should state '<undefined>' as type for the parameters.

    Solution:
    Obvious

    Problem:
    The first paragraph on page 3-33 in section 3.1.6.3.14 still talks about primary and secondary objects (or clones). In the last spec change primary objects where renamed to Cache objects and secondary objects(or clones) to CacheAccess objects. Note that cacheAccess object may be clones of cache objects, but that does not need to be the case.
    The text should be revised. The text also talks about an ObjectReference, which no longer exists, that text should be removed.

    Solution:
    Replace:
    ObjectRoot is the abstract root for any DLRL class. It brings all the properties that are needed for DLRL management. ObjectRoot are used to represent either objects that are in the Cache (also called primary objects) or clones that are attached to a CacheAccess (also called secondary objects). Secondary objects refer to a primary one with which they share the ObjectReference.
    With:
    ObjectRoot is the abstract root for any DLRL class. It brings all the properties that are needed for DLRL management. ObjectRoot are used to represent either objects that are in the Cache (also called cache objects) or objects that are attached to a CacheAccess (also called cacheaccess objects). Cacheaccess objects may be clones of cache objects, in that case they share the same OID.

    Problem:
    The table in section 3.1.6.3.19 regarding the intmap has an attribute defined called 'keys'. The type listed is 'string[]', but this should be 'integer[]', obviously.

    Solution:
    Obvious

    Problem:
    The text in section 3.1.6.2 states that any entity for which a generated class exists are indicated in italics. However when we look at the figure we see that this is not correct. The CacheBase class is incorrectly shown in italics, and the Selection class is incorrectly NOT shown in italics. The CacheListener should also not be in italics, as no class is generated for it, the same goes for the SelectionCriterion and the Collection. The ObjectHome however SHOULD be in italics.

    Solution:
    Make ObjectHome and Selection in italics
    Make CacheBase, CacheListener, SelectionCriterion and collection not in italics.

    Problem:
    In section 3.2.1.2.2 Implied IDL on page 3-60. A white space is missing in the attribute definition of the selections attribute between the attribute name and attribute type.

    Solution:
    Replace:
    readonly attribute FooSelectionSeqselections;
    With:
    readonly attribute FooSelectionSeq selections;

    Problem:
    In section 3.2.2.3.2.9 typo in section name ExtensionTable, it should be ExtensionTopic.

    Solution:
    Replace:
    3.2.2.3.2.9 ExtensionTable
    With:
    3.2.2.3.2.9 ExtensionTopic

    Problem:
    In section 3.2.3.2 IDL Model description on page 3-69 and 3-70 a module DLRL is mentioned twice, which does not exist. Track inherits from DLRL::ObjectRoot, it should be module DDS::ObjectRoot, same goes for valuetype Radar on page 3-70

    Solution:
    Replace:
    #include "dlrl.idl"
    valuetype stringStrMap; // StrMap<string>
    valuetype TrackList; // List<Track>
    valuetype Radar;
    valuetype Track : DLRL::ObjectRoot

    { public double x; public double y; public stringStrMap comments; public long w; public Radar a_radar; };
    valuetype Track3D : Track { public double z; };
    valuetype Radar : DLRL::ObjectRoot { public TrackList tracks; };
    With:
    #include "dlrl.idl"
    valuetype stringStrMap; // StrMap<string>
    valuetype TrackList; // List<Track>
    valuetype Radar;
    valuetype Track : DDS::ObjectRoot { public double x; public double y; public stringStrMap comments; public long w; public Radar a_radar; }

    ;
    valuetype Track3D : Track

    { public double z; }

    ;
    valuetype Radar : DDS::ObjectRoot

    { public TrackList tracks; }

    ;

    Problem:
    In section 3.2.3.4 Underlying DCPS Data Model the RADAR-TOPIC table is completely missing.

    Solution:
    Add:
    RADAR-TOPIC Topic to store all Radar objects, as well as the embedded attributes.
    OID Field to store the oid identifier.

    Problem:
    Faulty quotation marks can be found in the method description in sections 3.1.6.3.16, 3.1.6.3.17, 3.1.6.3.18 and 3.1.6.3.19. For example it states:
    o "remove - to remove the item with the highest index from the collection.
    But it should be:
    o remove - to remove the item with the highest index from the collection.

    All quotation marks should be removed!

    Solution:
    Remove quotation marks in section 3.1.6.3.16 for operations:

    • remove
    • added_elements
    • removed_elements
    • modified_elements
    • add
    • put
    • get
      Remove quotation marks in section 3.1.6.3.17 for operations:
    • add
    • remove
    • contains
    • added_elements
    • removed_elements
      Remove quotation marks in section 3.1.6.3.18 for operations:
    • keys
    • remove
    • added_elements
    • removed_elements
    • modified_elements
    • put
    • get
      Remove quotation marks in section 3.1.6.3.19 for operations:
    • keys
    • remove
    • added_elements
    • removed_elements
    • modified_elements
    • put
    • get
  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

instance_state of a DCPS instance becomes NOT_ALIVE_NO_WRITERS

  • Key: INBOX-219
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    It should clearly be stated what to do to the lifecycle of a DLRL object when the instance_state of the corresponding DCPS instance becomes NOT_ALIVE_NO_WRITERS.

    Solution:

    Our proposal is to mark this situation in the DLRL object, but not to start a new DLRL generation. There must be some mechanism however to notify the application about changes to the Liveliness of such an object. We propose to add a specific ObjectState called LIVELINESS_LOST, which is a separate state variable from the ObjectState. A transition to this state can be signalled by a callback method on the ObjectListener called "on_object_liveliness_lost". When liveliness is regained, the ObjectState can revert back to the LIVELINESS_ASSURED. A new callback should be added for that situation called "on_object_liveliness_regained". Similarly the ObjectHome should provide methods called "get_liveliness_lost_objects" and "get_liveliness_regained_objects".

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Indicate the semantics of merging separate topics into one single object

  • Key: INBOX-145
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    It needs to become clear how a situation is handled where a place- or extension topic is disposed, but the main topic is not, or vice-versa. What should be the result for the Object representing this combination?.

    Solution:

    Our proposal is that an object gets deleted if one or more of its constituent topics are deleted, and that it starts a new generation if one or more of its constituent topics starts a new generation. The same beaviour would then apply wrt Liveliness: the combination looses liveliness if one of the constituent topics does.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL object

  • Key: INBOX-184
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    What should happen to an object that passes a contentfilter once, but then its update gets blocked by the contentfilter? Currently the DLRL behaves as if no update was received, potentially resulting in the wrong assumption that the previous state is still the most recent state available.

    Solution:

    This problem cannot be solved without some support on DCPS ContentFilteredTopic level as well, since a special state needs to be introduced to represent instances that are blocked by a filter. The idea is to introduce a special state called NOT_COMPLIANT, that has similar properties to the DELETED state, except for the fact that it has another meaning. This NOT_COMPLIANT state can also be used for other purposes (See issue PT-DLRL-ARCH-0029).

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

How are deleted objects treated in a CacheBase and a Selection

  • Key: INBOX-153
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    It needs to be clarified how deleted objects are treated in a CacheBase and a Selection. In the update round in which they are reported as being deleted, are they still part of the members of that CacheBase/Selection or not? (See also section 3.1.6.4.1 last bullet.)

    Solution:

    Since deleted objects are no longer alive, we propose not to mention them in the members attribute of CacheBases/Selections. In the update round in which they become deleted they will be reported as being deleted in those CacheBases/Selections, but this deletion is executed immediately.

    Section 3.1.6.3.2
    Replace:

    · "A list of (untyped) objects that are contained in this CacheBase. To obtain objects by type, see the get_objects method in the typed ObjectHome.

    With:

    · A list of (untyped) objects (excluding the ones that are marked as deleted) that are contained in this CacheBase. To obtain objects by type, see the get_objects method in the typed ObjectHome.

    Section 3.1.6.3.7
    Replace:

    · obtain from a CacheBase a (typed) list of all objects that match the type of the selected ObjectHome (get_objects). For example the type ObjectRoot[ ] will be substituted by a type Foo[] in a FooHome.

    With:

    · obtain from a CacheBase a (typed) list of all objects (excluding the ones that are marked as deleted) that match the type of the selected ObjectHome (get_objects). For example the type ObjectRoot[ ] will be substituted by a type Foo[ ] in a FooHome.

    Section 3.1.6.3.9:
    Replace:

    · the list of the objects that are part of the selection (members).

    With:

    · the list of the objects (excluding the ones that are marked as deleted and the ones that no longer pass the filter) that are part of the selection (members).

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

FilterCriterion

  • Key: INBOX-189
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    When a Selection is in auto_refresh mode, normal operation is that it only evaluates objects in the update round in which they receive updates: objects that do not get updated have no reason to enter/exit a Selection. However, that mechanism is based on the assumption that the filter only evaluates the state of the object itself. What if the filter evaluates other things, like the state of related objects. Then the filter should also be re-applied if the state of such a related object changes.

    Solution:

    There may be a need to set the scope of a FilterCriterion: this scope will then define when and how objects should be re-evaluated by the Selection.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Proposal to make the is_xxx_modified operation optional

  • Key: INBOX-201
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    The is_xxx_modified operation (generated for each shared attribute in each DLRL object) is very heavy weight to implement, while it may not be used very much. We propose to make it optional, for example by a setting in the XML file, a setting on the corresponding ObjectHome, or by some QoS or something..

    Solution:

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Prevent writing contents of CacheAccess while 'invalid' relations exists

  • Key: INBOX-215
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    It is desirable to prevent an application from writing changes that are in itself inconsistent. Changes are inconsistent when for example a NIL pointer for a relation that was modeled as mandatory is still set (in predefined mapping, what would one put into the key values?!) or a relation to an object that is marked to be disposed in the next write operation (setting such relations is allowed, as long as they are reset again when writing the contents.). The latter is to be prevented to ensure receiving application do not get inconsistent data, i.e. a relation to a deleted object which could result in an AlreadyDeleted exception is to be prevented at all costs.

    To prevent such inconsistencies to be inserted into the system we propose to let the write operation throw an InvalidObjects exception to indicate the application has created an invalid state within the CacheAccess. To determine which objects are invalid an operation should be added to retrieve all invalid objects in the CacheAccess. And each ObjectRoot should have an operation to retrieve the names of the relations which cause the object to be marked as an invalid object.

    Solution:

    Add new Exception in the exception list on page 3-18:
    · InvalidObjects - To be thrown during the write operation of the CacheAccess to indicate invalid objects exist in the CacheAccess. An invalid object is defined as an object which has one or more invalid relation(s).

    On page 3-48 in section 3.2.1.2 IDL description the exception list should be expanded to include the following definition:
    exception InvalidObjects

    {string message;}

    ;

    Change the description of the write() operation on the CacheAccess on page 3-21, add the following:
    An InvalidObjects exception is raised if one of the objects contained within the CacheAccess has one or more invalid relation(s)

    Add the following operation to the CacheAccess class in figure 3-4 on page 3-16:
    get_invalid_objects()

    Add the following operation description to the end of the table of the CacheAccess in section 3.1.6.3.3, page 3-21.
    get_invalid_objects ObjectRoot[]

    Add the following description for operation get_invalid_objects() right after the description of operation delete_contract
    · Returns a list of all ObjectRoots which have one or more invalid relation(s). This operation should be used to recover from an InvalidObjects exception thrown by the write() operation. (get_invalid_objects)

    Add the following operation to the collection class in figure 3-4 on page 3-16
    get_invalid_elements()
    get_element_status()

    Add the following operations to the ObjectRoot class in figure 3-4 on page 3-16:
    get_invalid_relations()
    get_relation_status ()

    Add the following operation description to the end of the table of the Collection entity in section 3.1.6.1.15 on page 3-38
    get_invalid_elements <undefined element type>[]
    get_element_status RelationStatus
    value <undefined element type>

    Add the following description for operation 'get_invalid_elements()' right after the description of operation 'values':
    · Returns all elements which are seen as invalid by the DLRL. An element is invalid when it refers to an object with the write_state OBJECT_DELETED or when the collection is a composition, but the constituent object referred to by the element is also referred by another composition relation or when the relation is an association but the associated object referred to by the element does not correctly point back to the object. (get_invalid_elements)
    · Returns an enumeration indicating wether the element indicated by the value parameter is valid or invalid (and the exact relation why it is invalid). If the element is not known within the scope of the Collection than a NoSuchElement exception is raised. (get_element_status)

    Add the following operation description to the end of the table of the ObjectRoot entity in section 3.1.6.3.14 on page 3-34:
    get_invalid_relations string[]
    get_relation_status RelationStatus
    name string

    Add the following description for operation invalid_relations () right after the description of operation is_modified
    · Returns a list of relation names which are seen as invalid by the DLRL. A relation is invalid when it refers to an object with the write_state OBJECT_DELETED or when the relation is a NIL pointer but modeled as a mandatory relation (cardinality of 1) or when the relation is a composition, but the constituent object is also referred by another composition relation or when the relation is an association but the associated object does not correctly point back to the object. For relations that are collections the cardinality reason can not result in the relation being seen as invalid. (get_invalid_relations)
    · Returns an enumeration indicating wether the relation indicated by the name parameter is valid or invalid (and the exact relation why it is invalid). If no relation is known with that name within the scope of the ObjectRoot than a PreconditionNotMet exception is raised. (get_relation_status)

    On Section 3.2.1.2 IDL description on page 3-47 directly following the ObjectState enum add the following enum:
    enum RelationStatus

    { //The relation has no violations. VALID, //The relation is a NIL pointer but was modeled as a mandatory relation. CARDINALITY_VIOLATION, //The relation points to an object with read_state OBJECT_DELETED or //an object which was already garbage collected. LIVELINESS_VIOLATION, //The related object does not correctly associate itself with the 'owner' object //of this relation. ASSOCIATION_VIOLATION, //The related object is a constituent object in more then one composition relation. COMPOSITION_VIOLATION }

    ;

    On Section 3.2.1.2 IDL description on page 3-51 regarding valuetype ObjectRoot add the operation description:

    StringSeq get_invalid_objects();
    RelationStatus get_relation_status(in string name) raises (PreconditionNotMet);

    On Section 3.2.1.2 IDL description on page 3-55 regarding valuetype List add the operation description:
    LongSeq get_invalid_elements();
    RelationStatus get_element_status(in long index) raises (NoSuchElement);

    On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype StrMap add the operation description:
    StringSeq get_invalid_elements();
    RelationStatus get_element_status(in string key) raises (NoSuchElement);

    On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype IntMap add the operation description:
    LongSeq get_invalid_elements();
    RelationStatus get_element_status(in long key) raises (NoSuchElement);

    On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype Set add the operation description:
    /* To be properly typed in the generated derived classes:
    *

    • ObjectRootSeq get_invalid_elements();
    • RelationStatus get_element_status(in ObjectRoot value) raises (NoSuchElement);
      */

    On section 3.2.1.2.2 Implied IDL on page 3-62 regarding valuetype FooSet add the operation description:
    FooSeq get_invalid_elements();
    RelationStatus get_element_status(in Foo value) raises (NoSuchElement);

    In section 3.2.1.2 IDL description on page 3-57 regarding the CacheAccess add the exception InvalidObjects to the raises clause of the write operation.
    void write() raises (PreconditionNotMet, DCPSError, InvalidObjects, TimeOut);
    See issues XXX, XXX and XXX for details about the other exceptions and why the readonlymode exception was axed.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

getters of relationships

  • Key: INBOX-214
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    It is possible for getters of relationships between DLRL objects to throw a Notfound exception when the related object cannot be located by the DLRL. However if that related object arrives in a later update round the NotFound should be cleared and the getter should return the related object. The owner of that relation should be seen as modified and the is_xxx_modified operation for that relation attribute should return true even if the object itself was not explicitly updated in that update round.

    Example:
    Update round 1: We receive object Foo and detect it has a relation to object Bar, but this object is not known. The relation is thus set to a NotFound exception if accessed.
    Update round 2: We now receive the Bar object that is the target of the Foo objects bar relation. We do not receive an update for the Foo object itself though.

    We propose in situation like above to mark Object Foo as modified and set the received Object Bar as the target of Object Foo. Is_xxx_modified for that relation returns true. This should be explained in the specification.

    Solution:
    TBD

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Add attribute to CacheAccess (section 3.1.6.3.3)

  • Key: INBOX-169
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Currently it is only possible to retrieve the names identifying the object homes for which a CacheAccess contains objects, but it would be desirable if instead of getting an array of string you'd get an array of indexes.
    This would allow for a more performance friendly way for applications to jump to the code to handle objects of a specific type in a CacheAccess

    Solution:

    Add the following row to the attributes listing of the CacheAccess directly following the row for attribute type_names:
    contained_types integer[]

    Add the following description to the list of description for attributes on page 3-21 directly following the description of attribute type_names:
    o A list of indexes that represents the types for which the CacheAccess contains at least one object (contained_types).

    In the IDL description on page 3-57 section 3.2.1.2 add attribute definition in the interface CacheAccess:
    readonly attribute LongSeq contained_types;

    In figure 3-4 on page 3-16 add the contained_types to the attribute listing of class ObjectHome.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DCPSError also becomes a 'runtime' exception

  • Key: INBOX-228
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Currently the DCPSError is used in various operations to indicate an error occuring in DCPS, however it is implementation specific for which operations the DCPS is accessed. For example the getter of a simple attribute needs to access DCPS if the state of the object was not yet dereffed.
    And because it's up to the implementation to decide where to keep it management information, it also possible to get DCPS errors on operations which the specification does not define them. For example a refresh on a Selection or the get_objects on a CacheBase or ObjectHome may raise DCPSErrors in our implementation.

    To give a better flexibility we suggest to make the DCPSError exception runtime as well, especially since often such exceptions are not recoverable. In such cases that the exception IS recoverable we suggest introducing a specific exception for that case. For example introducing a timeout exception in the write operation of the CacheAccess to deal with the fact the DCPS DataWriter timed out, as that is recoverable, but an error code indicating the DataWriter is deleted is not recoverable.

    Solution:
    Replace (in section 3.2.1.1):
    Exceptions in DLRL will be mapped according to the default language mapping rules, except for the AlreadyDeleted exception. Since this exception can be raised on all methods and attributes (which is not possible to specify in IDL versions older than 3.0), it is not explicitly mentioned in the raise clause of each operation. Implementors may choose to map it onto an exception type that does not need to be caught explicitly, simplifying the DLRL code significantly.
    With:
    Exceptions in DLRL will be mapped according to the default language mapping rules, except for the AlreadyDeleted and DCPSError exceptions. Since these exception can be raised on all methods and attributes (which is not possible to specify in IDL versions older than 3.0), it is not explicitly mentioned in the raise clause of each operation. Implementors may choose to map it onto an exception type that does not need to be caught explicitly, simplifying the DLRL code significantly.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Describe exact event propagation in case of inheritance + multiple listener

  • Key: INBOX-150
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    In section 3.1.6.3.8 it is described how events that are not handled by child-objects are propagated to their parent objects. It is clearly described that when the callback function returns TRUE, the event will not be propagated to the parent Listener, otherwise it will. However, what should happen when two listeners are attached to the same Home and one of them returns TRUE and the other one returns FALSE?

    Solution:

    Clearly state that as long as only one of the Listeners returns FALSE, the event will be propagated to the parent listener.

    section 3.1.6.3.8
    Replace:

    Each of these methods must return a boolean. TRUE means that the event has been fully taken into account and therefore does not need to be propagated to other ObjectListener objects (of parent classes).

    With:

    Each of these methods must return a boolean. TRUE means that the event has been fully taken into account and therefore does not need to be propagated to other ObjectListener objects (of parent classes). In case of multiple listeners being attached to the same ObjectHome: as long as one or more of these listeners return FALSE, the event will be propagated to the parent classes, regardless of the number of listeners that returns TRUE.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clearly separate default mapping from pre-defined mapping

  • Key: INBOX-200
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    In Section 3.1.6.3.7 of the ObjectHome, there are descriptions for the create_object and the create_unregistered_object methods. They fail to mention that create_object may not be used for classes that have a keyDescription of "NoOid", and that create_unregistered_object may not be used for classes that have a keyDescription of "FullOid" or "SimpleOid". A PreconditionNotMet should be thrown in these cases.

    Solution:

    Section 3.1.6.3.7 on page 3-28
    Replace:

    · create a new DLRL object (create_object). This operation takes as parameter the CacheAccess concerned by the creation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Not satisfying either precondition will raise a PreconditionNotMet.

    With:
    · create a new DLRL object (create_object). This operation takes as parameter the CacheAccess concerned by the creation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Furthermore, this ObjectHome may not manage any topics that have their keyDescription set to "NoOid" in the XML mapping file. Not satisfying all these preconditions will raise a PreconditionNotMet.

    Section 3.1.6.3.7 on page 3-29
    Replace:

    · pre-create a new DLRL object in order to fill its content before the allocation of the oid (create_unregistered_object); this method takes as parameter the CacheAccess concerned with this operation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Not satisfying either precondition will raise a PreconditionNotMet.

    With:
    · pre-create a new DLRL object in order to fill its content before the allocation of the oid (create_unregistered_object); this method takes as parameter the CacheAccess concerned with this operation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Furthermore, this ObjectHome may only manage topics that have their keyDescription set to "NoOid" in the XML mapping file. Not satisfying all these preconditions will raise a PreconditionNotMet.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

The read_state of a cache object contains some typos

  • Key: INBOX-197
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    If we look at the state diagram of the read_state of the cache object, we can see several typos. With typos we mean transitions that are impossible (when reading other parts of the spec). the specification states that the DLRL works with update rounds, after the start of an update round updates are processed and applied onto objects, this may lead to state changes. Once the update round end, this information is cleared again.
    This last statement is of important, because if at the end of an update round the 'modification info' is cleared, then the read_state would return to NOT_MODIFIED after the end of updates signal (assuming it was NEW or MODIFIED) or it would be garbage collected if the state was DELETED. But this means there is no state transition between the NEW and MODIFIED state, not between the MODIFIED and DELETED states. There is also no transition from NEW to DELETED. These three transitions should thus be removed.
    Another 'typo' is that one transition is missing, namely from the start point directly to the DELETED state. Because it might happen that the DLRL detects a new object which is already disposed, and this is not something that can be ignored! This situation happens when a sample is read which has the following states (on DCPS level) view_state = NEW, sample_state = NOT_READ, instance_state = NOT_ALIVE_DISPOSED. In this case the DLRL cannot give this sample the state NEW, as it is disposed this update round and thus should not be shown as new, as that an incorrect view on things, the only way to go is to show it as DELETED, since ignoring such information is not a choice the DLRL can make. So this transition must be added.
    These changes produce the following diagram:

    The things said for the read_state of a cache object can also be said for the read_state of a cacheaccess object. An additional item missing is that the read_state of a cache access object in read_write mode can also go from start to void and then to end, in case of a local creation and then destruction through a write. This was not correctly mentioned, this also means the read_state diagram is valid for any usage of the cache access, the accompying text must be changed for this as well. The read_state of the cache access object is thus basically the same as the cache object, except the void state and it's transitions are added and some transitions have different descriptions

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Section 3.2.1.2.1 Generic DLRL Entities get_instance

  • Key: INBOX-196
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    For clarification purposes the generic IDL on page 3-59 in section 3.2.1.2.1 regarding the cache factory should mention the get_instance operation, in comments ofcourse.

    Solution:

    Add the following code to the CachFactory local interface definition:
    /* To be implemented as a static operation in the implementation:

    • CacheFactory get_instance();
      */
  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify listeners

  • Key: INBOX-225
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.4 it should state that listeners are only triggered if the related cache has updated_enabled returning true, that is not clear now from the text.

    Solution:
    Replace (on page 3-41):
    As described in Section 3.1.6.2, "DLRL Entities," on page 3-15, there are three kinds of listeners that the application developer may implement and attach to DLRL entities: CacheListener, ObjectListener, and SelectionListener. All these listeners are a means for the application to attach specific application code to the arrival of some events. They are therefore only concerned with incoming information.
    With:
    As described in Section 3.1.6.2, "DLRL Entities," on page 3-15, there are three kinds of listeners that the application developer may implement and attach to DLRL entities: CacheListener, ObjectListener, and SelectionListener. All these listeners are a means for the application to attach specific application code to the arrival of some events. They are therefore only concerned with incoming information. Listeners are only triggered if the related Cache has updates_enabled returning true, with the exception of the operations modifying the result of the updates_enabled operation (disable_updates/enable_updates).

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exceptions

  • Key: INBOX-142
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The get operation on the List and StrMap and IntMap classes should mention that a NoSuchElement is raised if the List/IntMap/StrMap does not contain an element for the index/key specified with the get operation.

    In the IDL description in section 3.2.1.2 on page 3-55, 3-56 add the raise clauses to the operations:
    For the list valuetype (also fix type of the first attribute of the List valuetype, operation put which takes an index, not a key as param) replace:
    ObjectRoot get( in long key );
    With:
    ObjectRoot get( in long index ) raises (NoSuchElement);

    For the StrMap valuetype:
    Replace:
    ObjectRoot get( in string key );
    With:
    ObjectRoot get( in string key ) raises (NoSuchElement);

    For the IntMap valuetype:
    Replace:
    ObjectRoot get( in long key );
    With:
    ObjectRoot get( in long key ) raises (NoSuchElement);

    In section 3.2.1.2.2 Implied IDL on page 3-61 and 3-62
    For the list valuetype (also fix type of the first attribute of the List valuetype, operation put which takes an index, not a key as param) replace:
    Foo get( in long key );
    With:
    Foo get( in long index ) raises (NoSuchElement);

    For the StrMap valuetype:
    Replace:
    Foo get( in string key );
    With:
    Foo get( in string key ) raises (NoSuchElement);

    For the IntMap valuetype:
    Replace:
    Foo get( in long key );
    With:
    Foo get( in long key ) raises (NoSuchElement);

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of find_home_by_name

  • Key: INBOX-137
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.3.4 on page 3-23 in the description of the operation find_home_by_name of the Cache entity it states that an already registered home can be retrieved using its name. It should be clarified that this name is the fully qualified name (in IDL sense, with '::' as seperator). The name of ObjectHome for Object Foo which is defined in module test thus becomes 'test::Foo'.

    Solution:

    Replace:
    o retrieve an already registered ObjectHome based on its name (find_home_by_name) or based on its index of registration (find_home_by_index). If no registered home can be found that satisfies the specified name or index, a NULL is returned.

    With:
    o retrieve an already registered ObjectHome based on its fully qualified name (in IDL sense, meaning for an ObjectHome representing class 'Foo' which was defined in module 'test' has the name "test::Foo") (find_home_by_name) or based on its index of registration (find_home_by_index). If no registered home can be found that satisfies the specified name or index, a NULL pointer is returned.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exception condition

  • Key: INBOX-139
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The explaination on page 3-24 for the create_cache operation states that a PreconditionNotMet is only raised if the usage of the access is not compatiable with the usage of the cache. It should also say that a PreconditionNotMet is raised if an access is attempted to be created while the cache is not yet enabled for pub sub.

    Solution:
    Add the new reason in the description.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Unclarities in section 3.1.4.2.3

  • Key: INBOX-209
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Various things are unclear in this section, for example the last bulleted list in this section does not take the Set type of a multi-valued attribute into account. A bullet needs to be added to state that the set does not contain an index key. Also replace 'row' with the word 'instance' in accordance with other issues. Also it needs to be indicated that in case of predefined mapping that the user defined keys identify the object, not the OID.
    In accordance with another issue, replace the word 'row' with 'instance'. Replace the word 'cell' with 'field'

    Solution:

    Replace:
    Mono-valued attributes and relations are mapped to one (or several) cell(s)7 in a single row whose key is the means to unambiguously reference the DLRL object (i.e., its oid or its full oid, depending on the owner class characteristics as indicated in the previous section):
    With:
    Mono-valued attributes and relations are mapped to one (or several) field(s)7 in a single instance whose key is the means to unambiguously reference the DLRL object (i.e. its oid, its full oid, or its user defined keys, depending on the owner class characteristics as indicated in the previous section):

    Replace (in the first bulleted list of the section):
    reference to another DLRL object (i.e., relation) -> as many cells as needed to reference unambiguously the referenced object (i.e., its oid, or its full oid as indicated in the previous section).
    With:
    reference to another DLRL object (i.e., relation) -> as many fields as needed to reference unambiguously the referenced object (i.e., its oid, its full oid, or its user defined keys as indicated in the previous section).

    Replace:
    Multi-valued attributes are mapped to one (or several) cell(s) in a set of rows (as many as there are items in the collection), whose key is the means to unambiguously designate the DLRL object (i.e., oid or full oid) plus an index in the collection.
    o For each item, there is one instance that contains the following, based on the type of attribute:
    o simple basic type -> one cell of the corresponding DCPS type;
    o enumeration -> one cell of type integer or string;
    o simple structures -> as many cells as needed to hold the structure;
    o reference to another DLRL object -> as many cells as needed to reference unambiguously the referenced object (i.e., its oid, or its full oid as indicated in the previous section).
    o The key for that row is the means to designate the owner's object (i.e., its oid or full oid) + an index, which is:
    o An integer if the collection basis is a list (to hold the rank of the item in the list).
    o A string or an integer9 if the collection basis is a map (to hold the access key of the item in the map).
    With:
    Multi-valued attributes are mapped to one (or several) field(s) in a set of instances (as many as there are items in the collection), whose key is the means to unambiguously designate the DLRL object (i.e., oid or full oid, or its user defined keys) plus an optional index in the collection.
    o For each item, there is one instance that contains the following, based on the type of attribute:
    o simple basic type -> one field of the corresponding DCPS type;
    o enumeration -> one field of type integer or string;
    o simple structures -> as many fields as needed to hold the structure;
    o reference to another DLRL object -> as many fields as needed to reference unambiguously the referenced object (i.e., its oid, its full oid, or its user defined keys as indicated in the previous section).
    o The key for that row is the means to designate the owner's object (i.e., its oid, full oid, or its user defined keys) + an optional index, which is:
    o An integer if the collection basis is a list (to hold the rank of the item in the list).
    o A string or an integer9 if the collection basis is a map (to hold the access key of the item in the map).
    o No index if the collection basis is a set (The item value field is implicitly the key in this case)

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

IDL interfaces for ObjectListener and FooListener are inconsistent

  • Key: INBOX-115
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The base IDL and implied IDL are inconsistent for ObjectListener and FooListener:

    1. The return values are "boolean" in the base class, "void" in the derived. Should be "boolean" for all.
    2. The comments in ObjectListener IDL imply that only on_object_modified has a Foo-specific version generated in the derived class. But FooListener has Foo-specific versions for all three operations. FooListener version is correct.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Need clarification on limitations of bi-directional association

  • Key: INBOX-127
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    Bi-directional associations involving multi-relations (either 1-to-N or M-to-N) and underspecified. Modifications to one side of a bi-directional relationship is supposed to be automatically reflected in the other side of the relationship, (see 3.1.3.2.2) but that is not always possible given the provided Collection interfaces.

    The behavior is clear if one of the multi-relations involved is a Set.
    A change one side of the association causes an add/remove on the Set side of the association.

    The behavior is interpretable if one of the multi-relations involved is a List. In a UML 1-to-N or M-to-N relationship, is is expected that there will not be duplicate entries in the "multi" side of the relationship. In other words, in a Foo<->*Bar relationship, the same Bar will not occur more than once in the Foo's list of Bars. Using this interpretation, you can interpret a n "add" to the non-List side of the relationship as implying that a new object is added to the end of the list, and a "remove" as implying that the object is removed from the List. In other words, we can treat the List just like a Set and allow changes to the association from both sides.

    The caveat is that you can't have duplicate entries in a List that is involved in a bi-directional association. (Then again, what if you modify the association from the List side, and you put duplicate values? Do we allow that?)

    Bi-directional assoications get very tricky when IntMaps or StrMaps are involved.

    If two maps are involved (e.g. IntMap to StrMap), then it is impossible to modify the association. If I add to it from the IntMap side, then I have to somehow specify the key to use on the StrMap side. The Collection interfaces provide no mechanism to to this.

    If only one map is involved (either 1-to-N or M-to-N), then I must to all modifications from the map side. Otherwise, I have no way to indicate the Map key when I modify the association.

    So, the specification need to be clarified on bi-directional associations:

    1. The behavior of a List in a bi-directional association must be clarified. Is what I said above correct, or should there be limitations on how you can use a List in a bi-directional association?

    2. The usage of IntMaps and StrMaps must be clarified. There are several possibilities:

    a. IntMaps and StrMaps are not allowed in bi-directional associations
    b. IntMaps and StrMaps are allowed, but you must make all modifications to the association from the Map side of the association.
    Map-to-Map associations are not allowed.
    c. All types of associations are allowed, and the OMG will add to the Collection API to provide the methods needed to set the map keys appropriately from either direction

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Request clarification on a WRITE_ONLY CacheAccess, cloning, and refresh()

  • Key: INBOX-123
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The spec is not completely clear on what you can and cannot do with a WRITE_ONLY CacheAccess.

    Is it legal to clone an object into a WRITE_ONLY CacheAccess, or are we only permitted to create brand new objects (via create_object) in a WRITE_ONLY CacheAccess?

    On a related note, is a CacheAccess::refresh() for a WRITE_ONLY CacheAccess always a noop, or should it throw an exception? It seems like it should thrown an exception (such as a WriteOnlyMode exception, which doesn't exist) to be consistent with CacheAccess::write, which throws a ReadOnlyMode exception when you call it from a READ_ONLY CacheAccess.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Diagrams in Fig 3.5 and Fig 3.6 look improperly captioned

  • Key: INBOX-124
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    It looks like the Fig 3.5 and Fig 3.6 diagrams have incorrect captions.
    I believe they should be corrected as follows:

    Fig 3.5: "read_state" and "write_state" should be swapped; the VOID diagram refers to read_state. The caption on the right-hand state chart should be "read_state of a Cache object in READ_ONLY or READ_WRITE mode".

    Fig 3.6's first state chart should have a caption that reads "read_state of a CacheAccess object in READ_ONLY or READ_WRITE mode"; the second state chart's caption should read "CacheAccess object", not just "CacheAccess"

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DDS DLRL Issue: Clarification on the use of a Set in a DLRL Query

  • Key: INBOX-112
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    In a DLRL Query, there are [] operators to access members of a collection. For a Set, is the [] operator used to determine whether the value is in the set or not? Or does a "contains" operator need to be added to the query language?

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Inconsistency in attribute definitions for valuetype ObjectRoot

  • Key: INBOX-140
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    On Section 3.2.1.2 on page 3-51 regarding valuetype ObjectRoot contains the attribute class_name, but it is missing in figure 3-4 and in the ObjectRoot description in the entity listings. It should either be removed from IDL, or be added to the PIM.

    Solution:
    We propose to remove it from the IDL since, it can also be obtained through the related home: on Section 3.2.1.2 on page 3-51 regarding valuetype ObjectRoot remove:
    readonly attribute ClassName class_name;

  • Reported: DDS 1.2 — Thu, 15 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Section 3.2.1.1 Mapping Rules regarding error reporting

  • Key: INBOX-152
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Section 3.2.1.1 Mapping Rules regarding error reporting states that an exception is only raised when future behavior is affected

    This is not exactly the case: Exceptions are also thrown when unrecoverable errors have occurred.

    Solution:
    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

In section 3.2.2.3.2.11 MultiAttribute.

  • Key: INBOX-216
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The description in section 3.2.2.3.2.11 MultiAttribute still refers to the indexField attribute of the MultiPlaceTopic as being mandatory. This is wrong, it is defined as an implied attribute in IDL.

    Solution:
    Replace:
    o A mandatory sub-tag to give the DCPS Topic where it is placed (multiPlaceTopic). This sub-tag follows the same pattern as placeTopic, except it has a mandatory attribute in addition to state the field needed for storing the collection index.
    With:
    o A mandatory sub-tag to give the DCPS Topic where it is placed (multiPlaceTopic). This sub-tag follows the same pattern as placeTopic, except it has an optional attribute in addition to state the field needed for storing the collection index, which should be used if the collection is a List or Map type.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Typos in section 3.2.1.2 IDL description

  • Key: INBOX-182
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.1.2 IDL description on page 3-48 and 3-49 for the definition of the ObjectListener the on_object_created and on_object_deleted operations are listed, however these operations are generated on the derived class 'Foo', thus should be contained within the comments just like operation on_object_modified. This was not correctly revised during the last spec revision.

    Solution:
    Replace:
    local interface ObjectListener

    { boolean on_object_created ( in ObjectRoot the_object); /**** will be generated with the proper Foo type* in the derived * FooListener * boolean on_object_modified ( * in ObjectRoot the_object); ****/ boolean on_object_deleted ( in ObjectRoot the_object); }

    ;
    With:
    local interface ObjectListener

    { /* Will be generated with the proper Foo type in the derived FooListener * * boolean on_object_modified (in ObjectRoot the_object); * boolean on_object_created (in ObjectRoot the_object); * boolean on_object_deleted (in ObjectRoot the_object); */ }

    ;

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Typos in section 3.1.6.4.3 & 3.1.6.4.4

  • Key: INBOX-135
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Sections 3.1.6.4.3 & 3.1.6.4.4 describe the sequence of listener triggers, they both state the selection listener is triggered first and then the object listeners. However this is not in correspondance with section 3.1.6.4.2, which states objectlisteners are triggered first!
    It's our suggestion to make everything uniform and let object listeners be triggered first and then selection listeners, as that sequence seems more logical. Naturally the paragraph of the selectionlistener should start with the word 'Then' instead of 'First' if they are swapped and vice virsa for the paragraph about ObjectListeners.

    Solution:
    Obvious

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Various typos in section 3.1.6.3.4, Cache

  • Key: INBOX-211
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem (1/5):
    Section 3.1.6.3.4 on the table on page 3-22 errornously states the operations load(), lock() and unlock(), which no longer exist since the previous specification update. They have been removed from the idl as well and figure 3-4, but not here.

    Solution (1/5):
    Remove load(), lock() and unlock() operations from the table on page 3-22

    Problem (2/5):
    Section 3.1.6.3.4 on page 3-24 still contains various descriptions about operations that no longer exist, namely load, deref, lock, unlock. All these operations were removed in the previous spec revision.

    Solution (2/5):
    Remove the following texts:
    o explicitly request taking into account the waiting incoming updates (load). In case
    updates_enabled is TRUE, the load operation does nothing because the updates are
    taken into account on the fly; in case updates_enabled is FALSE, the load operation
    'takes' all the waiting incoming updates and applies them in the Cache. The load
    operation does not trigger any listener (while automatic taking into account of the
    updates does - see Section 3.1.6.4, "Listeners Activation," on page 3-41 for more
    details on listener activation) and may therefore be useful in particular for global
    initialization of the Cache.
    o transform an ObjectReference to the corresponding ObjectRoot. This operation can
    return the already instantiated ObjectRoot or create one if not already done. These
    ObjectRoot are not modifiable (modifications are only allowed on cloned objects
    attached to a CacheAccess in write mode).
    o lock the Cache with respect to all other modifications, either from the infrastructure
    or from other application threads. This operation ensures that several operations can
    be performed on the same Cache state (i.e., cloning of several objects in a
    CacheAccess). This operation blocks until the Cache can be allocated to the calling
    thread and the waiting time is limited by a time-out (to_in_milliseconds). In case
    the time-out expired before the lock can be granted, an exception (ExpiredTimeOut)
    is raised.
    o unlock the Cache.

    Problem (3/5):
    In section 3.1.6.3.4 on page 3-24 in the middle of the page an indent is missing for the following text. And the paragraph is also ended with a ':', which should be a '.'. In the middle of the text, behind the first bold, italic word Cache it also has a ':', which should be a ';'

    Solution (3/5):
    Replace:
    The purpose of the CacheAccess must be compatible with the usage mode of the Cache:
    only a Cache that is write-enabled can create a CacheAccess that allows writing.
    Violating this rule will raise a PreconditionNotMet:

    With:
    The purpose of the CacheAccess must be compatible with the usage mode of the Cache;
    only a Cache that is write-enabled can create a CacheAccess that allows writing.
    Violating this rule will raise a PreconditionNotMet.

    Problem (4/5):
    Section 3.1.6.3.4 on page 3-22 right underneath the table gives an overview of the attributes of the Cache. The first bullet takes three attributes into one description, while everywhere else separate bullets are used for each attribute. This should be no different.

    Solution (4/5):
    Replace:
    · the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state), as well as the related Publisher (the_publisher) and Subscriber (the_subscriber).

    With:
    · the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state)

    · the related Publisher (the_publisher)

    · the related Subscriber (the_subscriber).

    Problem (5/5):

    In the description of the disable_updates() operation of the Cache in section 3.1.6.3.4 on page 3-22 still talks about the possibility of updates being interrupted. This 'possibility' was removed in the previous spec revision. An update round will always be finished normally.

    Solution (5/5):
    Replace:
    disable_updates causes incoming but not yet applied updates to be registered for further application. If it is called in the middle of a set of updates (see Listener operations), the Listener will receive end_updates with a parameter that indicates that the updates have been interrupted.
    With:
    disable_updates causes incoming but not yet applied updates to be registered for further application, any update round in progress will be completed before the disable updates instruction is taken into account.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

cloned objects

  • Key: INBOX-185
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    What should happen to cloned objects that, when the CacheAccess is refreshed, are no longer covered by any contract? You cannot just treat them as if they were deleted.

    Solution:

    Probably a special state needs to be introduced for this called NOT_COMPLIANT.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Extend the XML to allow optional relationships

  • Key: INBOX-141
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    Extend the XML to allow optional relationships (i.e. relationships with a cardinality of 0..1). This way it is always possible to explicitly allow NULL pointer relations, even in case of predefined mapping.

    Solution:

    An optional relationship should be accompanied by a boolean field that specifies whether the foreign keyfields should be interpreted or not.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

There is a lot of redundancy in the XML file.

  • Key: INBOX-156
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    Inheritance is redundantly modeled in both IDL and XML. What to do when there is inheritance according to IDL but not the XML or vice-versa? Also, it is not clear in case of multiple level inheritance (C extends B extends A) which topic should act as the main topic: for class C in this example, is the main topic the one corressponding to the highest parent (A), or the topic corresponding to the closest parent (B)?
    Finally, also the place topic description is very redundant: for each attribute located in the same place topic, the placetopic definition needs to be repeated.

    Solution:

    Our proposal is to not mention the extension topics in the IDL: just use normal class mapping and deduce from the IDL that two classes have an inheritance relationship.
    Furthermore we propose to define the topic definition (with its keydescription outside the scope of the class mapping: each attribute can then just refer to a known topic definition without repeating it.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Cache should have a getter to obtain its related DomainParticipant.

  • Key: INBOX-143
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    Currently it is not possible to navigate from a Cache to its underlying DomainParticipant. Such navigation may be convenient because the underlying DomainParticipant may be needed to manage statuses, control connectivity, change QoS settings and assert liveliness.

    Solution:

    Add an attribute to the Cache that refers to the underlying DomainParticipant.

    Section 3.1.6.2, Figure 3-4: Add a DomainParticipant class and a reference from the Cache to that DomainParticipant class. Name the reference "the_participant".

    Section 3.1.6.3.4: Add the following entry to the table:

    Cache
    attributes
    the_participant DDS::DomainParticipant

    Section 3.1.6.3.4
    Replace:

    · the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state), as well as the related Publisher (the_publisher) and Subscriber (the_subscriber).

    With:

    · the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state), as well as the related DomainParticipant (the_participant), Publisher (the_publisher) and Subscriber (the_subscriber).

    Section 3.2.1.2: Add to the IDL of the Cache interface the following line:

    readonly attribute DDS::DomainParticipant the_participant;

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Enable_all_for_pubsub operation

  • Key: INBOX-199
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Certain QoS settings on DCPS entities may conflict with DLRL usage, such as a history for samples, this cannot be represented within DLRL. Or setting auto_purge_disposed_samples_delay to something else then infinite or settings for coherent updates qos setings

    Solution:
    If such qoS settings are set in conflict with required settings for DLRL a PreconditionNotMet will be raised, explain this in the enable_allfor_pubsub operation.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Relationships to objects that have been deleted are not allowed.

  • Key: INBOX-191
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    It is possible for situations to arise where an ObjectRoot has a relation to an ObjectRoot which has already been deleted. Imagine we have a relationship between class Foo and Class Bar.
    In update round 1 we receive both Foo and Bar and create the relationship from Foo to Bar.
    In update round 2 the Bar object is disposed and thus the read_state is changed to DELETED, at the end of the update round the Bar object is actually deleted, accessing it from that moment on will raise the AlreadyDeleted exception. In this update round the relationship from Foo to Bar has not been reset (this is not unlikely in hybrid (DCPS and DLRL mixed) systems, or even DLRL only systems (topic samples are lost for example).
    If we try to navigate from Foo to the Bar object after update round 2, then we will get that Bar object, however accessing any operation gives us the (runtime) exception AlreadyDeleted.

    Because the above example deals with an error situation (The Foo object should have been updated in update round 2 and the relation to object Bar should have been reset, or the sample doing that shouldn't have been lost) we propose to clarify in the specification that it is NOT allowed to have a relationship to an object with the object state DELETED at the time of a refresh. Such relations should transparently be reset by the DLRL to a NotFound exception and the Foo object in the example should be marked as MODIFIED during the update round the deletion of the related object is detected, a call to the is_xxx_modified operation of the Foo object regarding relation Bar should return true.

    This also ensures that an application can NEVER get an AlreadyDeleted exception unless the application has specifically done something wrong (like maintain a reference to the Bar object in it's own application code and ignored the deletion event).

    Not allowing relationships to objects that are deleted ensures the same behavior is found for all situation involving relations, which is convinient for the application as it doesn't need to take exceptional situation into account but can be assured the middleware resolves such situations in a uniform manner.
    Foo is received but no Bar is available results in NotFound.
    Foo is received, Bar is received as disposed results in NotFound.
    Foo is received, Bar is received, Bar is then disposed results in NotFound.

    Solution:
    Explain the above behavior in the specification.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Remove the CacheDescription object

  • Key: INBOX-164
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The CacheDescription object is used within the create_cache operation on the CacheFactory only. It is a strange concept; a holder for a name and participant only. Instead one should simply provide the name and participant as parameters to the create_cache operation instead of needing to cumbersomely wrap it in a Cachedescription object.

    Solution:
    We propose to change the signature of the create_cache operation from
    create_cache(CacheUsage cache_usage, CacheDescription description)
    to
    create_cache(string name, CacheUsage cache_usage, DomainParticipant participant);
    Replace (in the table description of the CacheFactory on page 3-19)
    create_cache Cache
    cache_usage CacheUsage
    description CacheDescription

    With:

    create_cache Cache
    name string
    cache_usage CacheUsage
    participant DomainParticipant

    In the text on page 3-19 describing the create_cache operation change the text regarding the CacheDescription to reflect the change as well
    Replace:
    This method takes as a parameter cache_usage, which indicates the future usage of the Cache (namely WRITE_ONLY-no subscription, READ_ONLY-no publication, or READ_WRITE-both modes) and a description of the Cache (at a minimum, this CacheDescription gathers the concerned DomainParticipant as well as a name allocated to the Cache). Depending on the cache_usage a Publisher, a Subscriber, or both will be created for the unique usage of the Cache. These two objects will be attached to the passed DomainParticipant.

    With:
    This method takes as a parameter name, which represents the name allocate to the Cache; a paramater cache_usage, which indicates the future usage of the Cache (namely WRITE_ONLY-no subscription, READ_ONLY-no publication, or READ_WRITE-both modes) and a parameter participant, which contains the concerned DomainParticipant. Depending on the cache_usage a Publisher, a Subscriber, or both will be created for the unique usage of the Cache. These two objects will be attached to the passed DomainParticipant.

    (see next page for more)

    On page 3-59 in section 3.2.1.2 IDL description replace:
    /************************************************

    • CacheFactory : Factory to create Cache objects
      ************************************************/
      valuetype CacheDescription { public CacheName name; public DDS::DomainParticipant domain; }

      ;
      local interface CacheFactory

      { Cache create_cache ( in CacheUsage cache_usage, in CacheDescription cache_description) raises ( DCPSError, AlreadyExisting); Cache find_cache_by_name( in CacheName name); void delete_cache ( in Cache a_cache); }

      ;
      With:
      /************************************************

    • CacheFactory : Factory to create Cache objects
      ************************************************/
      local interface CacheFactory { Cache create_cache ( In CacheName name; in CacheUsage cache_usage, in DDS::DomainParticipant participant) raises ( DCPSError, AlreadyExisting); Cache find_cache_by_name( in CacheName name); void delete_cache ( in Cache a_cache); }

      ;

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

samples from the underlying DataReaders

  • Key: INBOX-180
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:

    Clearly state that it is not allowed to directly access information from the underlying DataReaders of a Cache Subscriber. Doing so might modify the status of these samples (for example their view_state and sample_state), potentially corrupting the Cache state as well.

    Solution:

    TBD.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Unclear sentence in section 3.1.6.1.1

  • Key: INBOX-206
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The sentence "Even if an object is not changeable by several threads at the same time, there is a need to
    manage concurrent threads of modifications in a consistent manner." Is very unclear as to what is meant. This should be clarified.

    Solution:
    ?

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Usage of Undefined unclear

  • Key: INBOX-148
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Everywhere where the word undefined is used it is not clear what this means, and the word may be used not only for Foo types, but also FooSelection classes, which makes it unclear what an undefined word means in the context. We suggest putting undefined between < and > and to state within the < and > the type which makes:
    <undefined> for Foo
    <undefined>Selection for FooSelection
    Etc.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify what happens with selection->refresh if auto_refresh is true

  • Key: INBOX-177
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.3.9 regarding the Selection the refresh operation needs to be clarified. I.E. the behavior if the selection is created with auto_refresh set to true (we suggest making it a no-op).

    Solution:
    On page 3-31 in section 3.1.6.3.9
    Replace:
    o request that the Selection updates its members (refresh).
    With:
    o request that the Selection updates its members (refresh). If the Selection was created with auto_refresh set to true, then this operation is considered a no-op.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify typical scenario for write mode of CacheAccess in section 3.1.6.5.2

  • Key: INBOX-158
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    Section 3.1.6.5.2 still talks about the clone_object operation, neglects to talk about the create_unregistered_object/register_objects operations and in step 5 it talks about modifying the attached. (attached what?!) it probably should say objects. Also between step 6 and 7 it should say

    Solution:
    Replace:
    3.1.6.5.2 Write Mode
    The typical scenario for write mode is as follows:
    1. Create the CacheAccess for write purpose (Cache::create_access).
    2. Clone some objects in it (ObjectRoot::clone or clone_object).
    3. Refresh them (CacheAccess::refresh).
    4. If needed create new ones for that CacheAccess (ObjectHome:: create_object).
    5. Modify the attached (plain access to the objects).
    6. Write the modifications into the underlying infrastructure (CacheAccess::write).
    7. Purge the cache (CacheAccess::purge); step 2 can be started again.
    8. Eventually, delete the CacheAccess (Cache::delete_access).
    With:
    3.1.6.5.2 Write Mode
    The typical scenario for write mode is as follows:
    1. Create the CacheAccess for write purpose (Cache::create_access).
    2. Attach some cloning contracts to it (CacheAccess::create_contract)
    3. Execute these contracts (CacheAccess::refresh).
    4. If needed create new objects for that CacheAccess (ObjectHome:: create_object or ObjectHome::create_unregistered_object followed by ObjectHome::register_object).
    5. Modify the objects (plain access to the objects).
    6. Write the modifications into the underlying infrastructure (CacheAccess::write).
    7. If needed create new contracts, delete/change exisiting contracts and then goto step 3 again.
    8. Purge the cache (CacheAccess::purge); step 2 can be started again.
    9. Eventually, delete the CacheAccess (Cache::delete_access).

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exceptions for add/put operations on List in section 3.1.6.3.16

  • Key: INBOX-224
  • Status: pending  
  • Source: PrismTech ( Erik Hendriks)
  • Summary:

    Problem:
    The add/put operations on the List in section 3.1.6.3.16, the add/remove operations on the Set in section 3.1.6.3.17, the put operation in the StrMap in section 3.1.6.3.18 and the put operation in the IntMap in section 3.1.6.3.19 should mention they raise a PreconditionNotMet if:

    • The owner ObjectRoot of the Collection is not contained within a (writeable) CacheAccess
    • The owner ObjectRoot has not yet been registered (i.e. has no identity)
    • Value is NIL
    • In case the Collection represents a MultiRelation (instead of a MultiAttribute)
      o The target (to be added) ObjectRoot has not yet been registered (i.e. has no identity)
      o The target (to be added) ObjectRoot is contained within a different CacheAccess or no CacheAccess
      o The target (to be added) ObjectRoot has already been deleted (different then marked for deletion!)

    The put operation of the List should also state a PreconditionNotMet is raised if the index provided is smaller then 0 or larger then the length of the list.

    In the IDL description in section 3.2.1.2 on page 3-55, 3-56 add the raise clauses to the operations:
    For the list valuetype (also fix type of the first attribute of the List valuetype, operation put which takes an index, not a key as param) replace:
    void add( in ObjectRoot value );
    void put( in long key, in ObjectRoot value );
    with:
    void add( in ObjectRoot value ) raises (PreconditionNotMet);
    void put( in long index, in ObjectRoot value ) raises (PreconditionNotMet);

    For the Set valuetype:
    Replace:
    void add( ObjectRoot value );
    void remove( ObjectRoot value );
    With:
    void add(in ObjectRoot value ) raises (PreconditionNotMet);
    void remove(in ObjectRoot value ) raises (PreconditionNotMet);

    For the StrMap valuetype:
    Replace:
    void put( in string key, in ObjectRoot value );
    With:
    void put( in string key, in ObjectRoot value ) raises(PreconditionNotMet);

    For the IntMap valuetype:
    Replace:
    void put( in long key, in ObjectRoot value );
    With:
    void put( in long key, in ObjectRoot value ) raises (PreconditionNotMet);

    In section 3.2.1.2.2 Implied IDL on page 3-61 and 3-62
    Replace for the FooList:
    void add( in Foo value );
    void put( in long key, in Foo value );
    With:
    void add( in Foo value ) raises (PreconditionNotMet);
    void put( in long index, in Foo value ) raises (PreconditionNotMet);

    Replace for the FooSet:
    void add( in Foo value );
    void remove( in Foo value );
    With:
    void add(in Foo value ) raises (PreconditionNotMet);
    void remove(in Foo value ) raises (PreconditionNotMet);

    Replace for the FooStrMap:
    void put( in string key, in Foo value );
    With:
    void put( in string key, in Foo value ) raises(PreconditionNotMet);

    Replace for the FooIntMap:
    void put( in long key, in Foo value );
    With:
    void put( in long key, in Foo value )raises(PreconditionNotMet);

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

clarify allowable (spec compliant) ways to implement ObjectReference[].

  • Key: INBOX-109
  • Status: pending  
  • Source: MITRE ( Charlotte Wales)
  • Summary:

    Need to clarify and/or enumerate allowable (spec compliant) ways to implement ObjectReference[]. The method definitions have return values or parameters specified by ObjectReference[]. Given that this is part of the platform independent model, it would appear that one could approach the implementation of this in C++ in one of two ways – as std::vector<ObjectReference *> or as an ObjectReference array. It is unclear which would be the preferred spec compliant way to do this. Alternatively, one could implement this as a language specific container, vector, list, map or whatever is the best performing container for the given situation, but would that not be in compliance with the spec at all?

  • Reported: DDS 1.1 — Fri, 14 Apr 2006 04:00 GMT
  • Updated: Wed, 27 Apr 2016 12:21 GMT
  • Attachments:

Thing

  • Key: INBOX-73
  • Status: pending  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Something else

  • Reported: UML 2.5 — Tue, 24 Nov 2015 17:18 GMT
  • Updated: Tue, 24 Nov 2015 17:44 GMT
  • Attachments: