[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sdo] ISSUE 124: Proposal
I think the proposal needs more refining too.
One thing is that there is another way to make properties "invisible": have them appear in SDO metadata, but say that getting them always returns null. This would probably alleviate Christophe's concern about keeping the DataGraph closed "in memory" (even though I was imagining that you would do it lazily anyway, only when/if somebody was asking for the orphans); and has the advantage that the user has control over where the orphans are going to show up.
The other, regarding 3, I am bit concerned about not knowing statically what the root element is going to be, that really makes it so that you need to have SDO on both ends of the wire (even if the SDO metadata originally came from XMLSchema). For me, an occasional "DataGraph not closed" exception (fixable by the SDO user) is preferrable. Another minor point related to this is that currently it is possible to stream the generated XML document out with only one pass over the SDO instance, I believe. If you need to first do one pass just to see if the data graph is closed, this nicety would be lost.
Radu
> -----Original Message-----
> From: Blaise Doughan [mailto:blaise.doughan@oracle.com]
> Sent: Monday, May 05, 2008 2:21 PM
> To: Christophe Boutard; sdo@lists.oasis-open.org
> Subject: Re: [sdo] ISSUE 124: Proposal
>
> Hello All,
>
> I do not expect that we will reach a proposal for SDO-124 by
> tomorrows call that Oracle can vote in favour of.
>
> Thoughts on the current proposals:
>
> * Obvious we agree with our own proposal.
> * The technical root solution is interesting. At the very least we
> feel that it is a necessary pattern to overcome the current
> containment requirements for models that cannot supply enough of
> their own. In order for us to accept this proposal there are a
> number of questions still to be answered (how is the technical
> root created?, what does the generated schema look like?, how do
> you indicate their use when XMLHelper.save is
> performed?). Can we
> develop this proposal further?
> * My objections/concerns with Ron's "combined" proposal
> are similar
> to Christophe's.
> * SDO-66, is it possible to demonstrate with an example
> that having
> SDO-66 eliminates the need for having SDO-124?
>
>
> -Blaise
>
> Christophe Boutard wrote:
> >
> > Hi Ron, everyone,
> >
> > Here are my comments inline...
> >
> > Best Regards,
> >
> > --Christophe
> >
> > * *
> >
> > *De :* Barack, Ron [mailto:ron.barack@sap.com] *Envoyé :*
> mercredi 30
> > avril 2008 10:40 *À :* Christophe Boutard; sdo@lists.oasis-open.org
> > *Objet :* RE: [sdo] ISSUE 124: Proposal
> >
> > Hi Christophe, everyone,
> >
> > I really want to try to resolve SDO-124 at next weeks
> meeting. Let's
> > try to find a solution that combines aspects of the various
> > approaches, and see if we can get everyone to sign up to it.
> >
> > The criticism that the orphan properties are visible
> through the API
> > is valid, and I agree that users will typically not want to
> see such
> > properties amoung their business objects. On the other hand,
> > {commonj.sdo}DataGraph is not a business object, it's already a
> > technical object, but I guess that not everything will be
> packed in a
> > DataGraph.
> >
> > <Christophe>
> >
> > I want to be sure to get your point. Are you talking about the
> > DataGraph object in memory or only its XML serialized
> format. The end
> > of the mail let me think that you are talking about the in
> memory object.
> >
> > If it only deals with XML that's fine for me but in the
> other case I
> > would not like to have to maintain the graph closure in memory
> >
> > </Christophe>
> >
> > One solution would be to make orphan properties even more
> special: to
> > make them invisible. That is, orphan properties appear
> neither in the
> > list of propertys defined by a type, nor in the instance
> properties of
> > the data object. They appear only when generating XSD from the type
> > metadata, and of course, in the XML generated by an
> XMLHelper.save().
> > This is essentially the behaviour that Oracle has proposed for
> > orphans, the only difference is that they are not generated, but
> > created as part of the type definition.
> >
> > <Christophe>
> >
> > It is almost the same question. You said that the "hidden"
> properties
> > only appear in the XML, so the question is why do we need to have
> > these properties definitions? I think that they can be generated by
> > the implementation at XML serialization time.
> >
> > More generally I'm really interested in the concept of having
> > invisible properties in SDO even independently of the Containment
> > discussion
> >
> > </Christophe>
> >
> > The burden is still on the user to define the appropriate orphan
> > properties, or to pack his objects in a DataGraph. Therefore, it is
> > still possible to generate GraphNotClosed exceptions. If we want to
> > make these exceptions a thing of the past, we need to have
> technical
> > root as a fallback mechanism. We'd need to extend the
> proposal as follows:
> >
> > <Christophe>
> >
> > I'm really not convinced by the first statement As I said
> in previous
> > emails I think that these technical things should be managed by the
> > implementation otherwise it will introduce a lot of
> complexity for the
> > users.
> >
> > I've also a particular question about the way objects are
> packed in a
> > DataGraph. I'm worrying about seeing some mechanisms that
> ensure the
> > DataGraph closure in memory.
> >
> > Let me try to develop this point...
> >
> > If a user adds an object in the graph, I suppose that the
> > implementation will automatically ensure that the object
> will be added
> > to the orphans if it has no container. If it is not done in
> that way I
> > don't see why the orphan properties are not only added at
> > serialization time.
> >
> > If I understand correctly we have three approaches :
> >
> > 1- The user defines the orphans properties in its Types if
> there is no
> > real DataGraph envelope.
> >
> > 2- The user has nothing to do if there is a DataGraph
> containing the
> > Orphans. I'm not sure about that, I think your answers to
> the previous
> > questions will help me...
> >
> > 3- If 1 or 2 are not enough, then the implementation will add the
> > Technical Root.
> >
> > Having these three approaches could be a good point but it
> will lead
> > to produce slightly different XMLs depending on the data graph
> > structure to serialize.
> >
> > </Christophe>
> >
> > 1. Define the type {commonj.sdo}TechnicalRoot as Frank has
> described
> > it, with 2 properties, a "businessRoot" and an "orphans" property.
> >
> > 2. The TechnicalRoot is specially treated during parsing (ie,
> > XMLHelper.load): it does not appear in the resulting
> XMLDocument. It
> > is simply an artifact of XML (de-)serialization.
> >
> > 3. Before serializing to XML, the various XMLHelper.save
> methods must
> > first assure that the data graph is closed. If it is not
> closed, the
> > serialization mechanism must insert a technical root object as the
> > root node of the graph before serializing it.
> >
> > <Christophe>
> >
> > Agree with the three statements as a definition of technical root.
> >
> > </Christophe>
> >
> > Like I said, I think it would be good (and I think, it's doable) to
> > resolve SDO-124 next week. Can I ask everyone to spend a few cycles
> > evaluating the proposals, bringing forward issues. It's also OK to
> > send an email saying if a solution is satisfactory... this
> gives me an
> > idea of how far we are from reaching consensus.
> >
> > Thanks,
> >
> > Ron
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> > *Von:* Christophe Boutard [mailto:christophe.boutard@xcalia.com]
> > *Gesendet:* Dienstag, 29. April 2008 22:24
> > *An:* Barack, Ron; sdo@lists.oasis-open.org
> > *Betreff:* RE: [sdo] RE: Spam detected by the Fortinet Antispam RE:
> > [sdo] ISSUE 124: Proposal
> >
> > Hi Ron,
> >
> > Here are my comments inline...
> >
> > -----Message d'origine-----
> > De : Barack, Ron [mailto:ron.barack@sap.com] Envoyé : mardi
> 29 avril
> > 2008 19:28 À : Christophe Boutard; sdo@lists.oasis-open.org Objet :
> > AW: [sdo] RE: Spam detected by the Fortinet Antispam RE:
> [sdo] ISSUE
> > 124: Proposal
> >
> > Hi Christophe,
> >
> > Drawing a distinction between "the role of Containment in the
> > DataGraph Closure and the concept of Composition" sounds very
> > interesting, but I'm not at all sure what exactly you are
> suggesting.
> > What API changes are you thinking about? Would containment
> no longer
> > be used in generating XML?
> >
> > <Christophe>
> >
> > I'm not thinking about API modifications but mainly in
> clarifying things.
> >
> > Let me try to elaborate...
> >
> > 1. From my point of view a DataGraph is a set of interconnected
> > DataObjects by Containment or Non Containment. At this point the
> > containment is nothing more than a specific kind of
> relationship. It
> > does not participate to the DataGraph definition
> >
> > 2. Then Containment itself should be defined as composition.
> >
> > 3. Finally from the XML serialization point of view, the concept of
> > DataGraph closure should be introduced. But only at this point in
> > order to maintain the Data Model and its XML serialized
> format totally
> > decoupled. This closure can rely on Containment and the orphans
> > management has to be integrated in order to ensure a tree based
> > structure because we are dealing with XML.
> >
> > </Christophe>
> >
> > Whether or not surfacing the orphans through the API is a bug or a
> > feature is a matter of taste. As with ChangeSummary, I imagine the
> > most common case to be that the user packs his data objects
> inside of
> > a {commonj.sdo}DataGraph, and since DataGraph has an
> orphans property,
> > the user will never have to worry about whether the graph is closed.
> > In this case, I don't think it's intrusive to say that
> DataGraph has
> > an orphans property that is accessible through the API... In fact,
> > there could be use-cases for it (though none come to mind
> right now,
> > other than some sort of error checking).
> >
> > <Christophe>
> >
> > I think I got your point but I'm not comfortable with a
> concept which
> > introduces something (I mean some properties) without any
> meaning in
> > the business model represented by the SDO Types. As said in my
> > previous email we have to be careful because having this kind of
> > orphan Properties always present in each DataGraph could lead us to
> > problems when trying to create relationships between two DataGraphs.
> >
> > But I'm interested in concrete use cases for that but
> basically if we
> > consider that a user has to choose between "containment" and "non
> > containment" for a relationship, I think that he should only be
> > focused on the semantic aspect of that choice which is
> "composition or
> > not".
> >
> > I may be wrong but currently I think these use cases will be more
> > technical than business oriented and in consequence the orphans
> > management should be hidden.
> >
> > </Christophe>
> >
> > I'm not sure that any of the proposals has any solution for
> managing
> > references that are unresolved within a graph, but
> resolvable in some
> > larger context. For that, we need a concept of identity. We
> also need
> > to be able to choose between whether we serialize object or
> their Ids.
> > Please see the 4th and 5th paragaphs of
> >
> http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200804
> > /msg00069.html for an idea of how SDO-66 (together with SDO-125 and
> > SDO-128) could maybe help here.
> >
> > <Christophe>
> >
> > I really like the idea of having KeyTypes compatible with Types in
> > order to represent a kind of "Hollow" DataObjects. Now from a DAS
> > point of view I've planned to start ASAP a discussion in order to
> > distinguish the difference between "null" and "not loaded"
> which means
> > when you call myDO.get("aDataObjectProperty") and you get
> null, does
> > it mean that the property is "loaded and null" or just "not loaded".
> > It seems to be again a new reason for being synchronized
> between DAS
> > and SDO TCs.
> >
> > </Christophe>
> >
> > Best Regards,
> >
> > Ron
> >
> > -----Ursprüngliche Nachricht-----
> >
> > Von: Christophe Boutard [mailto:christophe.boutard@xcalia.com]
> >
> > Gesendet: Dienstag, 29. April 2008 16:31
> >
> > An: sdo@lists.oasis-open.org
> >
> > Betreff: [sdo] RE: Spam detected by the Fortinet Antispam RE: [sdo]
> > ISSUE 124: Proposal
> >
> > Hi all,
> >
> > Due to OASIS membership issues, Xcalia members were
> temporarily unable
> > to post on and receive messages from the SDO3 mailing list
> since mid
> > past week.
> >
> > Now everything has been fixed, and I'll try to provide some
> points we
> > wanted to make about the containment issue.
> >
> > First from a pure TechnicalRoot point of view, I really
> like Frank's
> > proposal which make the TechnicalRoot more generic and so
> more easy to
> > standardize.
> >
> > Just as a quick reminder because his email has been sent
> one week ago,
> > I paste here his XSD proposal :
> >
> > <xsd:complexType name="TechincalRoot">
> >
> > <xsd:sequence>
> >
> > <xsd:element name="buisinessRoot" type="xsd:anyType" minOccurs="1"
> > maxOccurs="1" />
> >
> > <xsd:element name="orphans" type="xsd:anyType" minOccurs="0"
> > maxOccurs="unbounded" />
> >
> > </xsd:sequence>
> >
> > </xsd:complexType>
> >
> > <xsd:element name="xmlDataGraph" type="TechnicalRoot"/>
> >
> > From our point of view, this proposal is a very good one
> and we do not
> > have particular reasons for having a "per type" list of
> orphans except
> > the following example:
> >
> > Suppose that a Company has 10000 Employees by non
> containment. These
> > two employees share the same Address by non containment.
> >
> > Then the produced XML will be:
> >
> > <xmlDataGraph>
> >
> > <businessRoot xsi:type="tns:Company"
> >
> > <name>Company1</name>
> >
> > <employees>Employee1</employees>
> >
> > <employees>Employee2</employees>
> >
> > ...
> >
> > <employees>Employee10000</employees>
> >
> > </businessRoot>
> >
> > <orphans xsi:type="tns:Employee">
> >
> > <name>Employee1</name>
> >
> > <address>Address1</address>
> >
> > </orphans>
> >
> > <orphans xsi:type="tns:Employee">
> >
> > <name>Employee2</name>
> >
> > <address>Address1</address>
> >
> > </orphans>
> >
> > ...
> >
> > <orphans xsi:type="tns:Employee">
> >
> > <name>Employee10000</name>
> >
> > <address>Address1</address>
> >
> > </orphans>
> >
> > <orphans xsi:type="tns:Address">
> >
> > <street>Address1</street>
> >
> > </orphans>
> >
> > <xmlDataGraph>
> >
> > Now assume that a modification is made on the Address1
> instance. The
> > ChangeSummary will reference it but having all the orphans
> stored at
> > the same level will lead to check the 10000 employees in order to
> > locate the Address. I'm not sure this a SDO specific
> problem (it may
> > be more a XML parser / XPath / SDO implementation issue) but it may
> > raise a performance issue.
> >
> > Second point concerns a remark from Blaise saying that the
> > TechnicalRoot does not address the following use case where
> TypeA has
> > a containment property to TypeB and where we want to have B as the
> > document Root.
> >
> > Indeed the TechnicalRoot is not (currently) able to deal
> with that use
> > case for the following reason: We assume that containment
> > relationships are there for defining a "Composition" which
> means (IMO)
> > that the instance of Type B is only reachable from its parent.
> >
> > I think that the Oracle's proposal also consider contained
> object with
> > the same semantic and for that reason I'm a little bit lost
> by a use
> > case which consider a non identifiable object as a root.
> >
> > Now I'm back to the last proposal made by Ron (on SDO-124)...
> >
> > First, the good point is that it seems to allow everyone to produce
> > any kind of XML but based on Xcalia's TechnicalRoot implementation
> > experience, I'm a bit worrying to see that the concept of "orphan
> > properties" accessible from the API.
> >
> > As I said in our last document and during the F2F meeting,
> our first
> > TechRoot implementation was still visible for the users. We
> > encountered lots of problems when trying to merge data graphs (e.g.
> > create references from a datagraph to another) and mainly issues to
> > maintain the different "orphans" lists (not only data but also
> > information relative to change summaries).
> >
> > I would like to spend more time thinking about use cases based on
> > Ron's proposal and summarize up the Xcalia point of view.
> >
> > The first thing for us is to clarify the "containment" definition
> > which may imply a clean distinction between the role of
> Containment in
> > the DataGraph Closure and the concept of Composition.
> >
> > We believe that the Containment should only be used for the
> second role.
> >
> > IMO, this point is very well explained in Blaise's proposal.
> >
> > Then the second point consists in being able to serialize a
> non closed
> > graph. For this particular point, I think whatever the solution is
> > (Blaise's proposal, Ron's, TechRoot, a combination of all) the main
> > point is to consider the solution as an artifact for
> serialization and
> > not an evolution of the SDO model.
> >
> > In consequence users should not be aware of this technical
> things and
> > again (IMO) do not have to define themselves the orphan properties.
> >
> > Best Regards,
> >
> > --Christophe
> >
> > -----Message d'origine-----
> >
> > De : Radu Preotiuc-Pietro [mailto:radup@bea.com]
> >
> > Envoyé : mardi 29 avril 2008 03:11
> >
> > À : ron.barack@sap.com; sdo@lists.oasis-open.org
> >
> > Objet : Spam detected by the Fortinet Antispam RE: [sdo] ISSUE 124:
> > Proposal
> >
> > This is a very interesting proposal. Obviously I like the aspect of
> >
> > having DataGraph take on the extra duties. Two comments:
> >
> > 1) I think this "sdo:orphan" property is still special: even if one
> > can
> >
> > only get it, still, this get is different than the normal SDO get
> > which
> >
> > simply returns the reference. In this case, get() will involve
> > building
> >
> > the closure of the tree starting at the node the method is
> called on,
> >
> > because between any two calls, the set of orphans might
> change. That's
> >
> > not necessarily a show-stopper, but it's still "special behavior",
> > even
> >
> > compared with getChangeSummary().
> >
> > 2) I am wondering if we should also have the restriction
> that the type
> >
> > of the property must be "DataObject", so that we can use xsi:type to
> >
> > transmit the type information for the orphans. I don't
> think we need
> > the
> >
> > element names for the orphans, but the types we probably do.
> >
> > Radu
> >
> > > -----Original Message-----
> >
> > > From: ron.barack@sap.com [mailto:ron.barack@sap.com]
> >
> > > Sent: Monday, April 28, 2008 4:40 PM
> >
> > > To: sdo@lists.oasis-open.org
> >
> > > Subject: [sdo] ISSUE 124: Proposal
> >
> > >
> >
> > > Hi,
> >
> > >
> >
> > > I would like to formulate my idea, expressed in another
> >
> > > thread, as a proposed approach to issue 124.
> >
> > >
> >
> > > I think that the approach combines some of the positive
> >
> > > features of both Oracle's and XCalia's proposal, reuses a
> >
> > > pattern already used in SDO 2.1, therefore fits in well with
> >
> > > the rest of SDO, and is backwards compatible.
> >
> > >
> >
> > > Types may have one or more properties annotated as "orphan"
> >
> > > properties. Orphan properties that are defined through an
> >
> > > XSD are annotated with sdo:orphan="true". Orphan properties
> >
> > > that are defined through the API have an open content
> >
> > > property {commonj.sdo}Orphans with value true.
> >
> > >
> >
> > > This annotation may only be used on a read-only multivalued
> >
> > > property. The annotation may not be used on a property with
> >
> > > a data type.
> >
> > >
> >
> > > This annotation may only be used on a property with
> >
> > > containment="true".
> >
> > >
> >
> > > Calling a set method on a property, or modifying the list
> >
> > > returned by this property must throw an exception.
> >
> > >
> >
> > > Getting the value of this property (either through
> >
> > > DataObject.get() or through the static interface) returns a
> >
> > > list of objects that are referenced by the graph, but not
> >
> > > contained in the tree whose root is the node having the
> >
> > > "orphans" property and whose type matches the type of the
> property.
> >
> > >
> >
> > > {commonj.sdo}DataGraph gets a new property with the orphans
> >
> > > annotation, and type DataObject. However, other types may
> >
> > > also have a similarly annotated properties.
> >
> > >
> >
> > > The orphan property may appear in a tree: at the root or at
> >
> > > a leaf node. Types with orphan properties may even appear
> >
> > > with trees whose roots have orphan properties, or as
> >
> > > "brothers" of such, etc. In such cases, an implementation is
> >
> > > free to place the referenced object in the list of any
> >
> > > suitible property, however, the implementation must also
> >
> > > assure that the normal rules of containment apply, namely,
> >
> > > that the referenced object appears exactly once in the graph.
> >
> > >
> >
> > > Having such a property, it is easy to create a technical root
> >
> > > type. Users can specify if they what the technical root to
> >
> > > give the referenced objects in a "heap" or to sort them by type.
> >
> > >
> >
> > > By putting an orphan property on a Business Object (like
> >
> > > Employee, Department, Address), we get XML that looks like
> >
> > > the XML produced from Blaise's algorithm. That is, without
> >
> > > unexpected root nodes.
> >
> > >
> >
> > > Best Regards,
> >
> > > Ron
> >
> > >
> >
> > Notice: This email message, together with any attachments,
> may contain
> > information of BEA Systems, Inc., its subsidiaries and affiliated
> > entities, that may be confidential, proprietary, copyrighted and/or
> > legally privileged, and is intended solely for the use of the
> > individual or entity named in this message. If you are not the
> > intended recipient, and have received this message in error, please
> > immediately return this by email and then delete it.
> >
> >
> ---------------------------------------------------------------------
> >
> > 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_workgr
> oups.php
>
>
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]