|ron....@sap.com||Jan 22, 2008 10:39 am|
|Barack, Ron||Jan 22, 2008 10:42 am|
|von Mersewsky, Ulf||Jan 23, 2008 8:39 am|
|James Hart||Jan 23, 2008 8:51 am|
|Barack, Ron||Jan 23, 2008 9:10 am|
|yanghb||Jan 23, 2008 10:09 pm|
|Hongbo,Yang||Jan 24, 2008 12:02 am|
|Yang,Hongbo||Jan 24, 2008 12:26 am|
|Barack, Ron||Feb 11, 2008 3:08 pm|
|Subject:||RE: [sdo] [SDO-3]: Relationship of Type and Property to HelperContext|
|From:||Barack, Ron (ron....@sap.com)|
|Date:||Jan 23, 2008 9:10:03 am|
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.
-----Ursprüngliche Nachricht----- Von: James Hart [mailto:Jame...@roguewave.com] Gesendet: Mittwoch, 23. Januar 2008 17:52 An: von Mersewsky, Ulf; sd...@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).
-----Original Message----- From: von Mersewsky, Ulf [mailto:ulf....@sap.com] Sent: Wednesday, January 23, 2008 9:39 AM To: sd...@lists.oasis-open.org Subject: RE: [sdo] [SDO-3]: Relationship of Type and Property to HelperContext
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