AW: [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

sdo message