RE: [sdo] [SDO-3]: Relationship of Type and Property to HelperContext

["von Mersewsky, Ulf" <ulf.von.mersewsky@sap.com>]

Hi all!

I found a use-case where I could describe the problem of a hierarchy of
contexts.

Assume that there is a context C1 with a type T1. T1 is defined as
"open".
First a data object D1 of type T1 is created. As there are no other
contexts (so far) both D1 and T1 belong to C1.
Now imagine two other contexts, C2 and C3. Both contexts are cildren of
C1 and don't know about each other's existence.
A type T2 is defined in C2 while T3 is defined in C3.  Let's imagine the
types T2 and T3 could even be conflicting, they could have the same URI
and Name.
By definition you could add properties of type T2 or T3 to D1 because T1
is defined "open".    Now let's imagine serializing D1. The generated
XML will have 2 elements, both will have the 'xmi:type' attributes, but
each would have a different type in mind. No parser would ever be able
to parse the XML. When SDO is doing the parsing, it will always create
two objects of the same type, and at least one of the two will probably
be invalid. This leads us to the conclusion that a single datagraph
cannot contain elements from two contexts that possibly conflict with
each other.

If you're with me so far, let's go on and consider data graphs that
contain objects from a context and his parent, and see what trouble we
get into here.  Let's consider what should happen when an object of type
T2 is added to D1. Let's assume we allow this.  Now assume that the user
goes on to add an object of type T3. We've just said we don't want to
allow this..  By adding and object of T2, we have effectively pushed D1
into C2, but how should the poor data object (D1) know? It may know that
it was created in context C1 and is of type T1 from C1. It couldn't know
if it should accept properties of type T2 or T3. We can also imagine
that the objects being added to D1 are complex, and that it would take
significate effort to determine if any element of the subtree has an
object of T2 or T3.

We think that allowing data graphs to mix objects from different
contexts, even if those contexts are related, can only lead to
complexity and problems. On the other hand, we see the need to use
"parent" contexts when new contexts are being defined. Our proposal,
though, is to copy (or create a delegating proxy for) every type from a
parent context. T1' is the copied version of T1 in context C2.
Applications would create objects with type T1' rather than T1. If
object D1' is created from T1', then it knows that it should accept
properties of types from contexts C2 (and C1) only.

Hopefully it isn't too confusing.

Best regards,
Ulf