AW: [sdo] ISSUE 124: Another attempt

Title: 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:] 
Gesendet: Mittwoch, 7. Mai 
2008 09:12
An: Barack, Ron; 

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:] 
Envoyé : mercredi 7 mai 2008 
16:34
À : 
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