OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[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]