For Protocol it extends Class which is redundant and probably unhelpful...

since Protocol is a specialization of Block (which extends Class) this is not helpful, because one needs to know that this stereotype
would be used instead of <<Block>> (since one can not have both a generalization and specialization of a stereotype on the same element)...

Block here is the more fundamental than the metaclass Class... but neither should be specified redundantly in the model...
it is just not helpful... what would be helpful is defining the fundamental thing in the definition of the UAF elements

For Protocol it extends Class which is redundant and probably unhelpful...

since Protocol is a specialization of Block (which extends Class) this is not helpful, because one needs to know that this stereotype
would be used instead of <<Block>> (since one can not have both a generalization and specialization of a stereotype on the same element)...

Block here is the more fundamental than the metaclass Class... but neither should be specified redundantly in the model...
it is just not helpful... what would be helpful is defining the fundamental thing in the definition of the UAF elements

Even thought the UML Standard does not explicitly state this, extends are inherited by specializations of Stereotypes...

1. The UML standard show examples of specializations of stereotypes that do not extend metaclasses indicating that extends are inherited see Fig. 12.21
2. ExtendEnds are forms of Association Ends which are inherited normally (and there is nothing to the contrary in the standard that they are treated any differently)
3. SysML also uses this... e.g. see Fig. 8.8 of SysML 1.7 where BoundReference does not show an extends (but gets it from EndPathMultiplicity)...

so given UAF... I think most everything that extends Element is wrong... because for example, you do not want to be able to put the stereotype
<<OperationalActivity>> on anything but a UML/SysML Activity... but Activity is MeasureableElement which is a UAFElement which extends Element, so therefore <<OperationalActivity>> can be put technically on anything (e.g. a Comment)... so this is wrong and needs to be fixed

since PropertySet types things... one can be tighter about what it extends... it should extend Classifier rather than Element

p74 8.1.7 View Specifications::Resources::Structure

1) identifier - Rs-Sr, missing'

Definition: defines the physical resources, e.g. capability configuration(s)/system(s) and interactions necessary to implement a specific set of OperationalPerformer(s).'

2) CapabilityConfiguration and System are not physical resources (as Figure 8:56 shows)

3) ResourceArchitecture specialised elements - System, SecurityEnclave allowed but missing from Fig 8:56. All elements of a taxonomy tree should be shown. If not then the parent should not be shown and particular individual child elements shown.

'Concerns: reference the resource structure, connectors and interfaces in a specific context.'
4) Meaningless - what does 'reference the ...' mean? 'In a specific context'? Back inAbitraryConnector territroy. How can you possibly determine that these elements represent the allowed view content when there is no clear set of concerns which triples formed from the elements should address?

5) Is nothing carried by a ResourceExchange? If so elements are needed on Fig 8:56 to describe this.

6) Protocol is not involved in any triple. There appears to be a triple involving ProtocolImplementation but not Protocol. If there is a triple involving Protocol expected then additional elements are required. If there is no triple involving Protocol delete it.

7) Similarly there is no triple involving Measurement - again define one including a relationship element or remove.

8) The 'ResourcePerformer IsCapableToPerform Function' triple has no connection to the structural and interface concerns. It makes no sense to try and describe functional, interfaces and structure on the one architecture view. Function should be the subject of e behaviour-oriented 'view specification' e.g. Resources Process - Rs-Pr. The IsCapableToPerform and Function elements should be remoed from Fig 8:56

The Normative References section refers to both versions 1.0 and 1.1 of XML Schema for no obvious reason

GIOP and IIOP versioning must be clearly and consistently specified. There are numerous places within the Firewall Traversal FTF report's version of CORBA chapter 15 where certain specific GIOP or IIOP versions are explicitly cited, but the newly introduced versions are not mentioned. For example, the definition of the GIOP_version field of the GIOP Message Header in section 15.4.1 says "The major GIOP version number of this specification is one (1); the minor versions are zero(0), one (1), and two (2)." GIOP versions 1.3, 1.4, and 1.5 are not addressed. Similarly, table 15-3 does not even show messages such as Request and Reply applying to GIOP versions 1.4 and 1.5. There are other occurances where the intent may not be so obvious. I recommend revisiting every reference to a particular GIOP or IIOP version in chapter 15 to make sure that the new versions (including 1.3) are correctly addressed. Where possible, I recommend replacing lists of versions with text such as "version 1.2 and up" that does not need to be revised every time a new version is introduced.

The Action struct has a member of type ActionRequired, name 'action' .

The JacORB (1.4 beat 4) IDL comiler/parser complains that the declarator has already been used (identifier collision):

Error in CosLicensingManager.idl, line:28(17): Declarator action already defined in scope. ActionRequired 1 error(s). Errors compiling CosLicensingManager.

The Corba spec (2.4 00-10-01) states in the Lexical definitions that upper and lower case are regarded as the same. Is the use of the Action & action definitions twice then a collision? Can the the action variable be renamed in the IDL file to something like action_required without affecting any other specification /

Given a property P defined by type B as PROP_NORMAL, two types T1 and T2 inherit from B but each strengthens the mode to PROP_READONLY and PROP_MANDATORY respectively. Then is there an implied strengthening to PROP_MANDATORY_READONLY in a further derived type T3 which inherits from both T1 and T2? Related to this, the OMG spec has nothing to say about waht exception should be raised by an attempted "weakening" of a property mode by a sub-type or exactly what is construed as a "weakening" with multiple inheritance. Another slightly different senario is: Given a property P defined by type B as PROP_READONLY, two types T1 and T2 inherit from B with one of them "strengthening" the mode of B to PROP_MANDATORY_READONLY. Is deriving a type T3 from both T1 and T2 legal?

The spec does not clearly describe the relationship between connectors and components (inheritance?) and homes (manageability).

>From paragraph 7.4 (programming model for connectors) we can conclude the following:
1. connectors are derived from CCMObject
2. connectors (can) have a (keyless) Home

The formal spec in the earlier paragraphs of chapter however does not seem to mention any of this or of the consequences like:
a) can we explicitly define a connector as the managed component of a Home?
b) can we define explicit factories for connectors in a Home managing that connector?
c) can we declare a component as an explicit derivative of a connector?

I think the answers to a) and b) should be yes. This should be clearly described in the spec.
In principal the answer to c) could also be yes but I think that is a bad idea since the connector is definitely not meant to be used as a general purpose component. I feel this should actually be explicitly prohibited by the spec.

C++ as a language is not just the core language but also STL that accompanies with it. There are lots of useful algorithms in STL, but they are not very easily used with the C++ mappings of CORBA Sequences. Step closer to this usability would be to add a member typedef that would tell the type of items the sequence contains - this would allow implementing an STL iterator compliant types more easily. And really nice thing would be if the mapping would have begin() and end() functions like STL containers do.

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.

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

;
valuetype RelationDescription

;
valuetype ListRelationDescription : RelationDescription

;
valuetype IntMapRelationDescription : RelationDescription

;
valuetype StrMapRelationDescription : RelationDescription

;
typedef sequence<RelationDescription> RelationDescriptionSeq;

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

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

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

;
With:
local interface ObjectListener

;

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

;
With:
local interface FooSelection : DDS::Selection

;

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

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

;

With:
local interface SelectionListener

;

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

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.

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>

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>

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

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

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.

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>

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;

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

Solution:
Obvious

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.

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.

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.

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

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"

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"

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

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

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

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;

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.

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.

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

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.

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.

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.

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.

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

valuetype FooImpl : Foo

;

Solution:
TBD

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

;
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

;

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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?

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.

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.

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

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

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?

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?

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.

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

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

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

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.

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

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.

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:

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

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

;

Solution:
TBD

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.

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

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

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.

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

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

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.

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.

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

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.

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)

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?

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.

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

;

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

;

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

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

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();
  */

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.

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

;
valuetype Track3D : Track

;
valuetype Radar : DDS::ObjectRoot

;

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

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.

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

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?

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.

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.

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

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

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

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.

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.

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.

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

  ;

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.

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;

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

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

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.

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.

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

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.

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.