Hi Everyone,

I took an action item to rewrite the chapter on projection without requiring
"object identity" and without an "undefined state". Here is a first draft:

4.14.3

The Project method

The DataHelper.project() method is used to move data between contexts. This
functionality is useful when moving data between loosely coupled applications,
or when imposing alternate structures on existing models, for instance when
imposing an XML containment hierarchy on data coming from a relational database.
This section describes the behavior of the project method in terms of an object
O1 with type T1 in HelperContext C1 and a second context C2 that defines a Type
T2, that is compatible with T1 according to the definition in section 4.5.4 The
method DataObject O2 = C2.getDataHelper().project(O1);

MUST return a DataObject O2 such that O2.getType() is T2 [COR04140301]. The
definition of Type Compatibility given in section 4.5.4 means that for every
property P1 that can be accessed on O1 there is a corresponding property P2
accessible from O2. The types of the two corresponding properties are either
directly compatible (i.e., P1.getType() is compatible with P2.getType()) or one
side is compatible with the keyType of the other side (i.e., either
P1.getType().getKeyType() is compatible with P2.getType() or P1.getType() is
compatible with P2.getType().getKeyType()). The behavior of the project method
when moving from complex objects into keys or back again is dealt with is
section 4.14.4. For each property P2 in O2 that is directly related to a
property P1 in O1, the project method MUST initialize the values of the property
such that: [COR04140303]

1.

If P1.getType().isDataType() is true then O1.get(P1) is equal toO2.get(P2) 2. If P1.getType().isDataType() is false then
C2.getEqualityHelper().equals(O2.get(P2), C2.project(O1.get(P1))

If O1 and O2 are both sequenced, then the order of the elements in the sequences
MUST match. [COR04140302]

It is possible that a valid data graph cannot be projected into another context,
because it violates the restrictions implied by the target context's metamodel.
Such restrictions include those implied by the type's containment structure,
e.g., there can be no objects in the projected containment graph that have more
than one container. For instance, consider an object O1, with Type T1, in
context C1. Assume that it has 2 properties, "a" and "b", neither of which are
marked as being a containment property. Then it could be legal to set the value
of these properties to the same object, N1. Now consider a second type, T2, in
context C2, that is compatible with T1 but in which the properties "a" and "b"
are both marked as being containment properties. Then the DataObject O1 cannot
be projected into the context C2, because the object N1 would project to an
object that has conflicting containment properties. Attempting to perform such
a projection is a user error and results in undefined behavior.