[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sdo] RE:[sdo] [SDO-2]: Can data graphs contain only data objects froma single context?
Hi Ron, Section 2.2 Agree. Perfect as worded. Section 4.15 I agree in principal, but suggest a couple of changes in the wording. I believe the following version basically says the same thing, only with slightly better English grammar and it definitely does not exclude the possibility of a future (or implementation-specific) parent HelperContext concept. If you and everyone else is OK with the following wording, I propose we resolve this issue. PROPOSAL: A HelperContext provides access to a consistent set of SDO helpers. This is intended to allow applications to define metadata that is independent of and protected from metadata in other applications. The set of helpers returned by a single context have access the same SDO metadata, that is, HelperContexts define the scope or visibility of a set of SDO types. Every SDO type is conceptually contained by (associated with) the HelperContext from which it is retrieved. Since every DataObject has a type, every DataObject is, in turn, indirectly associated with a HelperContext. In order to assure consistent behaviour, every DataObject in a data graph, that is, in the transitive closure reachable from some root node, must be associated with the same HelperContext. Creation and access to HelperContexts, other than the default context, is implementation dependent. Thanks, Frank. "Barack, Ron" <ron.barack@sap.com> 02/11/2008 08:44 AM To "von Mersewsky, Ulf" <ulf.von.mersewsky@sap.com>, <sdo@lists.oasis-open.org> cc Subject [sdo] RE:[sdo] [SDO-2]: Can data graphs contain only data objects from a single context? Hi Everyone, First, I'm moving Frank's response to this mail thread, where I think it belongs. Now, I want to make a proposal for the resolution of ISSUE-2 (some aspects of ISSUE-3 are also addressed) Lines refer to the document as may be downloaded from http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26863/OASIS%20SDO%20For%20Java%20Spec.doc PROPOSAL: Section 2.2, line 143: Add the following text: Applications that run on application servers commonly share memory with other applications. In such environments, it is essential that each application can define its own type system and be assured that the metadata is protected from influence from other applications that may have conflicting definitions for some types. This concept of a registry of types that is local to each application is supported by SDO's HelperContext. Section 4.15: replace with the following text A HelperContext provides access to a consistent set of SDO helpers. This is intended to allow applications to define metadata that is independent of and protected from metadata in other applications. The set of helpers returned in a single context have access the same SDO metadata, that is, HelperContexts define the scope or visibility of a set of SDO metadata. Every SDO type may be thought of as belonging to a HelperContext. Since every DataObject has a type, each DataObject is indirectly associated with a HelperContext. In order to assure consistent behaviour, each DataObject in a data graph, that is, in the transitive closure reachable from some root node, must be associated with a single HelperContext. Creation and access to HelperContexts, other than the default context, is implementation dependent. Best Regards, Ron ------------------------------------------------------------------------ Now, Frank's email: ----------------------------------------------------------------------- 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 > > > --------------------------------------------------------------------- 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 -----Ursprüngliche Nachricht----- Von: von Mersewsky, Ulf [mailto:ulf.von.mersewsky@sap.com] Gesendet: Mittwoch, 23. Januar 2008 17:49 An: sdo@lists.oasis-open.org Betreff: [LIKELY JUNK][sdo] RE:[sdo] [SDO-2]: Can data graphs contain only data objects from a single context? I used the wrong subject for my last mail. I wanted to send it to this thread. Here comes a link to my mail on oasis so that we could discuss it here under SDO-2: http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200801/m sg00036.html 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]