DDS12 — Simplify Relation Management

The purpose of the DLRL has been described as being able “to provide more direct access to the exchanged data, seamlessly integrated with the native-language constructs”. This means that DLRL should offer applications an OO-view on the information model(s) they use. In this view, objects behave in the same way as ordinary, native language objects.
Providing intuitive object access and object navigation should be key-benefits of DLRL compared to plain DCPS usage, where instances and their relations need to be resolved manually. Object navigation in DLRL therefore needs to be simple and intuitive, just like navigating between objects in any ordinary native OO-language.
It is in this aspect that DLRL falls short: object navigation is not simple and intuitive, since it requires intermediate objects (RefRelations and ObjectReferences) that abstract applications from the navigable objects. The purpose of these intermediate objects was to serve as some sort of smart pointers, that abstract applications from knowledge about the exact location and even about the existence of objects (to allow a form of lazy instantiation).
However, since the potential benefits from smart pointer management are rather dependent on the underlying target language, the DLRL specification does not address them and only explains the effort that an application should do in the absence of any smart pointer support. This results in the following problems:
The way in which a DLRL implementation solves pointer arithmetic is not standardized and may change from vendor to vendor and from language to language.
When smart pointer arithmetic is not available, applications will be expected to do lots of extra relational management, which is not in the scope of most application programmers.

Proposed Resolution:

Simplify relation management by removing all intermediate relation objects from the API (Reference, Relation, RefRelation, ObjectReference, ListRelation and MapRelation). Navigation of single relations is done by going directly from ObjectRoot to ObjectRoot (simplifying the IDL object model as well). Implementations can still choose to do smart resource management (e.g. lazy instantiation), but they should do so in a fully transparent way, one that is invisible to applications.
This approach also makes the PIM and PSM (which deviated quite a lot from eachother with respect to these intermediate relation-like objects) more consistent.

Proposed Revised Text:

Section 3.1.5.2, 2nd paragraph, 1st sentence: “DLRL classes are linked to other DLRL classes by means of Relation Objects”. This should be replaced with “… by means of relations.”.

Change the Object Diagram of Figure 3.4. (an alternative Object Diagram will be provided).

Change the table immediately following Figure 3.4 by removing the ObjectReference, Reference, Relation, RefRelation, ListRelation, StrMapRelation and IntMapRelation entries from it.

Remove the foot-note directly following this table (starting with with number 1) that says: “The specification does … (lazy instantiation).”

Section 3.1.6.3.2: Remove the sequence of ObjectReference attribute from the CacheAccess table and from the explanation below it. As a replacement, see T_DLRL#2 and T_DLRL#3.

Section 3.1.6.3.2: Remove the deref method from the CacheAccess table and from the explanation below it.

Section 3.1.6.3.3: Remove the sequence of ObjectReference attribute from the Cache table and from the explanation below it. As a replacement, see T_DLRL#2 and T_DLRL#3.

Section 3.1.6.3.3: Remove the deref method from the Cache table and from the explanation below it.

Section 3.2.1.2.1: Remove the following lines from the CacheAccess and Cache interface:
readonly attribute ObjectReferenceSeq refs;
ObjectRoot deref( in ObjectReference ref) raises (NotFound);

Section 3.1.6.3.5: Remove the sequence of ObjectReference attribute from the ObjectHome table, and from the explanation below it.

Section 3.2.1.2.1: Remove the following line from the ObjectHome interface:
readonly attribute ObjectReferenceSeq refs;

Section 3.1.6.3.5: Change the entire explanation of the auto_deref attribute from:
“a boolean that indicates if ObjectReference corresponding to that type should be implicitly instantiated (TRUE) or if this action should be explicitly done by the application when needed by calling a deref operation (auto_deref). As selections act on instantiated objects (see section 3.1.6.3.7 for details on selections), TRUE is a sensible setting when selections are attached to that home.”
to:
“a boolean that indicates whether the state of a DLRL Object should always be loaded into that Object (auto_deref = TRUE) or whether this state will only be loaded after it has been accessed explicitly by the application (auto_deref = FALSE).”

Section 3.1.6.3.5: Change the entire explanation of the deref_all method from:
“ask for the instantiation of all the ObjectReference that are attached to that home, in the Cache (deref_all).”
To:
“ask to load the most recent state of a DLRL Object into that Object for all objects managed by that home (deref_all).”

Section 3.1.6.3.5: Change the entire explanation of the underef_all method from:
“ask for the removal of non-used ObjectRoot that are attached to this home (underef_all).”
To:
“ask to unload all object states from objects that are attached to this home (underef_all).”

Section 3.1.6.3.6: Replace all occurrences of ObjectReference with ObjectRoot in the ObjectListener table. Also remove the second parameter of the on_object_modified method.

Section 3.1.6.3.6: Change the explanation of on_object_created from:
“… this operation is called with the ObjectReference of the newly created object (ref).”
to:
“… this operation is called with the value of the newly created object (the_object).”

Section 3.1.6.3.6: Change the explanation of on_object_modified from:
“This operation is called with the ObjectReference of the modified object (ref) and its old value (old_value); the old value may be NULL.”
To:
“This operation is called with the new value of the modified object (the_object).”

Section 3.1.6.3.6: Change the explanation of on_object_deleted from:
“… this operation is called with the ObjectReference of the newly deleted object (ref).”
To:
“… this operation is called with the value of the newly deleted object (the_object).

Section 3.1.6.3.10: Replace all occurrences of ObjectReference with ObjectRoot in the SelectionListener table.

Section 3.2.1.2.1: Change in the IDL interfaces for ObjectListener en SelectionListener the following lines from:
local interface ObjectListener

;

local interface SelectionListener

;

To:

local interface ObjectListener

;

local interface SelectionListener

;

Section 3.2.1.2.2: Change in the IDL interfaces for ObjectListener en SelectionListener the following lines from:

local interface FooListener: DDS::ObjectListener

;

local interface FooSelectionListener : DDS::SelectionListener

;

To:

local interface FooListener: DDS::ObjectListener

;

local interface FooSelectionListener : DDS::SelectionListener

;

Section 3.1.6.3.13: Remove the ObjectReference attribute from the ObjectRoot table, and from the explanation below it.

Section 3.2.1.2.1: Remove the following line from the IDL in the ObjectRoot:
readonly attribute ObjectReference ref;

Section 3.1.6.3.13: Change the following sentence from:
“In addition, application classes (i.e., inheriting from ObjectRoot), will be generated with a set of methods dedicated to each shared attribute:”
To:
“In addition, application classes (i.e., inheriting from ObjectRoot), will be generated with a set of methods dedicated to each shared attribute (including single- and multi-relation attributes):”

Section 3.1.6.3.14 can be removed (ObjectReference).

Section 3.2.1.2.1: Remove the following lines from the IDL:

/*****************

• ObjectReference
  *****************/
  struct ObjectReference { DLRLOid oid; unsigned long home_index; }

  ;
  typedef sequence<ObjectReference> ObjectReferenceSeq;

Section 3.1.6.3.15 can be removed (Reference).

Section 3.1.6.3.20 can be removed (Relation).

Section 3.1.6.3.21 can be removed (RefRelation).

Section 3.1.6.3.22 - Section 3.1.6.3.24 can be removed (ListRelation, IntMapRelation and StrMapRelation).

Section 3.2.1.2.1: Remove the following lines from the IDL:

/********************************

• Value Bases for Relations
  *********************************/

valuetype RefRelation

;

valuetype ListRelation : ListBase

;

valuetype StrMapRelation : StrMapBase {
struct Item

;
typedef sequence <Item> ItemSeq;
private ItemSeq m_refs;
boolean is_composition();
};

valuetype IntMapRelation : IntMapBase {
struct Item

;
typedef sequence <Item> ItemSeq;
private ItemSeq m_refs;
boolean is_composition();
};

Section 3.2.1.1: 1st paragraph after the numbered list of DLRL entities, remove the following sentence: “(with the exception of ObjectReference, …. , so that it can be embedded). Section 3.2.1.2.2: Change the following lines in IDL from:

valuetype FooStrMap : DDS::StrMapRelation { // StrMap<Foo>
…
valuetype FooIntMap : DDS::IntMapRelation { // IntMap<Foo>

To:

valuetype FooStrMap : DDS::StrMap { // StrMap<Foo>
…
valuetype FooIntMap : DDS::IntMap { // IntMap<Foo>

Section 3.2.2.3.1: Remove the “Ref” value from the allowed list of patterns, so change the templateDef . The templatedef then changes from:
<!ATTLIST templateDef name CDATA #REQUIRED
pattern (List | StrMap | IntMap | Ref) #REQUIRED
itemType CDATA #REQUIRED>

To (see also Issues T_DLRL#7 and T_DLRL#8):

<!ATTLIST templateDef name CDATA #REQUIRED
pattern (Set | StrMap | IntMap) #REQUIRED
itemType CDATA #REQUIRED>

Section 3.2.2.3.2.3, 2nd bullet: Remove the “Ref” pattern from the list of supported constructs.

Section 3.2.3.2: Replace the forward valuetype declaration for RadarRef with a forward declaration of type Radar, so change from:
valuetype RadarRef // Ref<Radar>
To:
valuetype Radar;

Section 3.2.3.3: Remove the following line from the XML (in both XML examples):
“<templateDef name=“RadarRef”
pattern=“Ref” itemType=“Radar”/>”

see above