SDO 120 - Projection & Undefined State

Hello All,

Before SDO 3.0 goes to public review, I want to be sure we all agree on
the behaviour of the project operation (http://www.osoa.org/jira/browse/SDO-120
).  As a means to move data from one HelperContext to another
HelperConext we (Oracle) find the project method quite useful, our
concern lies in the following constraint:

    DataObject O1 = hc1.getDataFactory().create(...);

    DataObject O2 = hc2.getDataHelper().project(O1);

    O1 == hc1.getDataHelper().project(O2);

It is this constraint that according to section 4.14.3, "The
project operation leaves the DataObject O1, and all
objects in the transitive closure reachable from O1 in an undefined
state.".  My interpretation of "undefined state" is that this
DataObject is not guaranteed to work correctly if you try to use it.
This constraint is non-trivial to implement and not without is problems
(see Problematic Use Cases 1 & 2 below), so we need to agree that
the constraint is worth having.

Primary Use Case - Applying an XML Representation

Once we moved from tree's to graphs we needed a new way to apply an XML
structure to our DataObjects.  In this scenario you would have two
HelperContexts, one with metadata based on a data source (graph) and
another based on an XML schema (tree).  When you want to send the
results of a data source query as XML you simply project between
HelperContexts.  Note that in this scenario the DataObjects
representing the data source data are in an undefined state until the
XML HelperContext passes control back:

    DataObject dataSourceDO = // obtained from data source some how

    DataObject xmlDO =
xmlHelperContext.getDataHelper().project(dataSourceDO);  //
dataSourceDO is now in undefined state

    xmlHelperContext.save(xmlDO);

    dataSourceHelperContext.getDataHelper().project(xmlDO);  //
dataSourceDO is back to a define state

In this scenario, the DataObject is never modified in the XML
HelperContext, but had to exist in an undefined state regardless.

Problematic Use Case 1 - DataObject Shared by 2 Graphs

In this use case DataObjects O1 & O3 both have a reference to
DataObject O2.  

    Before Projection:        O1 --non-containment --> O2
<--non-containment-- O3

    After Projection of 01:   O1 (undefined state)
--non-containment --> O2 (undefined state)
<--non-containment-- O3

This means that after O1 is projected, DataObject O3 is in a defined
state, but O2 which it is referencing is not.

Problematic Use Case 2 - Dereferenced Objects

What happens to objects that have been dereferenced while projected? 
Presumably it becomes the responsibility of the person who dereferenced
the object to project it back to the original HelperContext?  If so how
does that person know that a projection is necessary and where to
project it back to?

    HelperContext 1:  O1 --non-containment--> O2

    HelperContext 2:  O1' = hc2.getDataHelper().project(O1);

    HelperContext 2:  O1'.getDataObject("o2").detach();

    HelperContext 1:  hc1.project(O1');  leaves O2 in an undefined
state?

-Blaise