[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
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.
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:
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.
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----- 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]