Hi James,
I think a HelperContext is somewhat larger than a namespace. A HelperContext defines a set of types that are consistent with each other.
I think most of us had in mind something like the set of types known to a single JEE application. To give some background, the HelperContext, specifically the default HelperContext (HelperProvider.getDefaultContext()) is a more application-server friendly version of the *Helper.INSTANCE singletons, currently used in 2.1 (Do we need an issue to deprecate them?)
If you want to think in terms of XSD, then a HelperContext contains all the types defined in a schema, including the types defined in "imported" namespaces. If you think in Java, a TypeHelper contains all the data classes used by an application. In any of the industrial XSDs that Frank likes to talk about, quite a few namespaces will be mixed. I don't think we want to define the concept of HelperCOntext to be so fine, that users have to regularly switch between them.
Ron
-----Urspr黱gliche Nachricht-----
Von: James Hart [mailto:James.Hart@roguewave.com]
Gesendet: Mittwoch, 23. Januar 2008 17:52
An: von Mersewsky, Ulf; sdo@lists.oasis-open.org
Betreff: [LIKELY JUNK]RE: [sdo] [SDO-3]: Relationship of Type and Property to HelperContext
If we are going to bind meta information in the SDO tighter with the
concepts put forth into XSD would it be feasiable to look at contexts as
namespaces. That would simplify the way to look at a context and
interact between them. A each context would contain types only defined
in some namespace. Then the context helper could contain references to
all contexts and when a type is requested it would require a namespace
and the correct type would always be grabbed from the correct context
and contained within it.
Then your use case would become invalid, if you created Context 2 and
then tried to create/load context 3 but it had the same namespace it
should be able to define new types or extend types from the original
namespace but if it redefined a type than that would actually be an
error. Then context 2 and context 3 logically would be the same
context.
Just some random thoughts. I just think this idea might help us define
the interaction between contexts and make it much easier to manage types
and even cross over different contexts into the same datagraph if each
type referenced it's own context (namespace).
~James
-----Original Message-----
From: von Mersewsky, Ulf [mailto:ulf.von.mersewsky@sap.com]
Sent: Wednesday, January 23, 2008 9:39 AM
To: sdo@lists.oasis-open.org
Subject: RE: [sdo] [SDO-3]: Relationship of Type and Property to
HelperContext
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php