[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [LIKELY JUNK]RE: [sdo] [SDO-3]: Relationship of Type and Propertyto HelperContext
Hi Ulf, I had intended to cc the mailing list with this, but in my rush to vacation it looks like I forgot. Sorry about the mistake. Frank. "von Mersewsky, Ulf" <ulf.von.mersewsky@sap.com> wrote on 02/04/2008 08:24:07 AM: > Hi Frank, > > I noticed that you didn't send that answer to the mailing list. Was > this your intent? > > So far I discussed your thoughts with Ron and Stefan but wouldn't it > be interessting for the whole group too? > > Hear you in the call tomorrow. > > Best regards, > Ulf > > -----Ursprüngliche Nachricht----- > Von: Frank Budinsky [mailto:frankb@ca.ibm.com] > Gesendet: Freitag, 25. Januar 2008 20:07 > An: von Mersewsky, Ulf > Betreff: [LIKELY JUNK]RE: [sdo] [SDO-3]: Relationship of Type and > Property to HelperContext > > Hi Guys, > > I haven't had a chance to think about this in depth, but here are the > thoughts I've had so far. > > 1. I agree that mixing types form C2 and C3 (i.e., not hierarchically > related contexts) would be bad and shouldn't be done. > 2. I'm not sure if #1 requires SDO to enforce this at all time (i.e., thow > an exception when one tries to do a set). > 3. Maybe it could instead, for example, fail at serialization time if > C2.getXMLHelper().save() is used to serialize the graph, but it finds an > object of type T3 (which is not visible in C2). > 4. Another possiblity is that a DataGraph's context would start out to be > the context in which the root object was created (e.g., C1), but whenever > an object of a type in a child context (e.g. C2) is created, the datagraph > context changes to the child context. Then if somebody tries to add an > object of type T3 from an incompatible context, it would be an error - > although, I'm still not sure if immediate failure is what we want for > this. > 5. Certainly, when loading an XML document that contains type T2, > C2.getXMLHelper().load() would need to be used (i.e., the context that > knows about all the types). > > My mental model is that if a context is considered the container of a type > then we could consider parent helperContexts as a containment relationship > as well. For example T1 is contained by C1, C1 is contained by C2. So, > logically T1 is also contained by C2. > > Anyway, that's all I've thought about so far - I'm off on vacation now > until Feb 4. > > Frank. > > > "von Mersewsky, Ulf" <ulf.von.mersewsky@sap.com> wrote on 01/23/2008 > 11:39:13 AM: > > > 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]