Re: AW: [sdo] ISSUE 124: Another attempt

[Frank Budinsky <frankb@ca.ibm.com>]

Hi guys,

I agree that we need to clarify the question about what is the root (1 or 
2) in this example.

I like the proposal, but wonder if instead of just saying that the orphan 
element in Type {commonj.sdo}DataGraph has this special serialization 
behavior, we could create a new annotation, e.g., 
{commonj.sdo/xml}orphanHolder, which can be used anywhere to get this 
special behavior using any suitable user-defined property.

    <xsd:element name=?orphans? type=?xsd:anyType? 
sdox:orphanHolder="true" minOccurs=?0? maxOccurs=?unbounded?/> 

Frank.




"Barack, Ron" <ron.barack@sap.com> 
05/07/2008 12:25 PM

To
"Christophe Boutard" <christophe.boutard@xcalia.com>, 
<sdo@lists.oasis-open.org>
cc

Subject
AW: [sdo] ISSUE 124:  Another attempt






Hi Christophe,
 
The first part of your question is maybe something that should be 
addressed in the JSR 235 group, it seems to be unclear in the spec.  I 
would have expected that the object provided by the user is the data 
graph's root object (or the child of the root object, if you consider the 
wrapper supplied by data graph).   I would have expected the business root 
is contained by the DataGraph, effectively detached from your node "1".
 
Whether "1" should be serialized is somewhat orthogonal to the rest of the 
discussion.  I would say that 3.0 should be consistent with 2.1.1.
 
For the orphan object, yes, this is exactly what I am saying.  The 
actually "orphan" is node "5".  Node "7" is serialized only as a part of 
serializing node "5".
 
Ron

Von: Christophe Boutard [mailto:christophe.boutard@xcalia.com] 
Gesendet: Mittwoch, 7. Mai 2008 09:12
An: Barack, Ron; sdo@lists.oasis-open.org
Betreff: RE: [sdo] ISSUE 124: Another attempt

HI Ron, everyone,
 
First of all your proposal sounds good to us.
 
I?ve added a picture to this email in order to be sure of the expected 
behavior when you pack objects into a data graph.
 
So here is the scenario:
 
I would like to pack my data into a data graph and the object provided by 
the user is ?2?.
 
I expect that ?1? will be considered as the business root because it is 
the container of ?2?.
 
Then ?4? will be added to the orphans list.
 
It should be the same for ?5? even if the referenced object is ?7?. The 
thing is that ?7? is referenced by containment and should not be 
considered as orphan.
In that case we have to retrieve the first object without container and 
mark it as orphan. In our case it is ?5?.
 
I hope everything is clear?
 
Thanks,
--Christophe
 

 
De : Barack, Ron [mailto:ron.barack@sap.com] 
Envoy� : mercredi 7 mai 2008 16:34
� : sdo@lists.oasis-open.org
Objet : [sdo] ISSUE 124: Another attempt
 
Hi Everyone, 
In Tuesday's call there seemed to be some consensus that performing a 
XMLHelper.save() operation using a {commonj.sdo}DataGraph as an argument 
should never throw a GraphNotClosed exception.  That is, DataGraph should 
act as a technical root, and any orphans referenced but not contained in 
the DataGraph?s business root should be serialized as children of the 
DataGraph. 
I've been looking at trying to make a proposal out of this.  It seems to 
me the most natural place to describe this behavior is in Chapter 12, 
which deals specifically with the XML serialization of DataGraphs.
I would like to add the following paragraph at line 3424 (based on the 
word document 
http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26863/OASIS%20SDO%20For%20Java%20Spec.doc 
)
________ 
The serialization of a DataGraph, whether invoked through a DAS or 
java.io.Serializable or in a Web service, includes the transitive closure 
of all DataObjects reachable from the DataGraph?s root object, whether or 
not the DataObject are contained, directly or indirectly, by the root 
DataObject.  DataObjects that are referenced but not contained must be 
included in the ?orphan? elements that are part of the DataGraphs XML 
representation.  Each ?orphan? element is serialized as part of the 
containment tree in which it is located, and any DataObjects referenced 
but not contained in this tree must also be included among the DataGraph?s 
orphans, so that the transitive closure is obtained.  References to 
orphaned DataObjects follow the normal rules of XML serialization.  The 
serialization of a DataGraph never throws an exception because the graph 
is not closed.
____________________ 
The XSD at the end of the chapter would also need to be modified: 
  <xsd:complexType name="BaseDataGraphType" abstract="true"> 
    <xsd:sequence> 
      <xsd:element name="models" type="sdo:ModelsType" minOccurs="0"/> 
      <xsd:element name="xsd" type="sdo:XSDType" minOccurs="0"/> 
      <xsd:element name="changeSummary" 
                   type="sdo:ChangeSummaryType" minOccurs="0"/> 
      <xsd:element name=?orphans? 
                   Type=?xsd:anyType? minOccurs=?0? 
maxOccurs=?unbounded?/> 
    </xsd:sequence> 
    <xsd:anyAttribute namespace="##other" processContents="lax"/> 
  </xsd:complexType> 
______________________ 
Another small change will have to be made around line 3407, but this is 
mainly editorial, and can be left to the editors.
__________________________ 
You might notice in the above text that not only is the orphaned 
DataObject itself serialized, but also the complete containment tree in 
which the object is located.  I think this is necessary: first of all, 
because an object reachable through getContainer() is non-the-less 
reachable, and otherwise we don't really have transitive closure.  More 
pragmatically, I think it will otherwise be very difficult to create the 
URIs that reference the objects in any efficient manner?suppose the 
reference to a leaf is found first, then later a reference to the root.
Of course, I'd agree to this proposal as a compromise, but I do want to 
point out what we are losing by declaring this functionality on DataGraph, 
rather than creating a new kind of property, which DataGraph happens to 
have.  With this proposal, DataGraph contains ChangeSummary, XSD, the 
business object, and now orphans,  If we want to create a new type of 
container, eg, with only orphans, we cannot do it.  The functionality is 
specific to DataGraph.  It seems to me allowing users to define such types 
is not a bad thing.  Effectively, that is the only difference between last 
week's proposal and this one.
Best Regards, 
Ron