Hello All,

XML serialization refers to two concepts in SDO: 1. The XML representation used when a data object goes through Java serialization (see SDO 2.1 section 6 "Java Serialization of DataObjects"). Here we are sending data objects from one SDO environment to another SDO environment. In this arena we can focus on making the transfer of data as efficient and portable as possible (which may require Xcalia's technical root). 2. The XML representation used when a data object is marshalled by XMLHelper. Here we are sending a message that may or may not be received by an SDO client. This is the compelling use case, as it relates to how SDO interacts with other technologies (Web Services, Java EE, .Net, etc.). In this case if we marshal/save an employee data object it would be unexpected to have the result wrapped in a technical root. Here is where the Oracle proposal (SDO-124) fits.

Oracle Proposal (SDO-124) and SDO 2.1

SDO 2.1 allows the current metadata: Department --containment --> Address Department --containment --> Employee Employee --non-containment --> Address

With this SDO 2.1 compliant metadata it is possible to create a graph that can not be serialized. All you need to do is to specify an instance of Address on an instance of Employee that is not containment by an instance of Department. The algorithm in the SDO 2.1 spec requires that you specify enough containment relationships (and obey them). The Oracle algorithm (SDO-124) makes the assumption that if you specify containment relationships you are specifying enough (just like SDO 2.1), in addition if no containment relationships are specified then there is special treatment for them.

Comparing the Containment Proposals

Oracle Proposal (SDO-124) One of the interesting aspects of the Oracle proposal (SDO-124) is that XML messages can be sent relative to a particular SDO type. This is very useful for DAS implementations that want to have per type find operations and then send this as an XML message. If the underlying metamodel had a containment relationship between Department and Address then the Oracle proposal (SDO-124) could produce an XML message wrt Department and another XML message wrt Employee.

Xcalia Proposal The above use case is not addressed by the Xcalia proposal.

SAP's proposal (SDO-66) The SAP proposal (SDO-66) does address this use case, my understanding of that proposal is that a set of metadata would need to be defined per root type and stored in its own instance of HelperContext. DAS would realize data in a HelperContext, and then project that data into another HelperContext that corresponds to the root type of the query. The onus would be on the user to ensure that the types between the HelperContexts are compatible.

-Blaise

Barack, Ron wrote:

Hi,

I'd like to revive this mail thread. I think the first question has been answered in Xcalia's document. To me, the compelling use-case is that we have two SDO based applications that want to communicated. Neither cares about specifying an XSD to which the message should conform, they just want to send SDOs over an XML wire.

That leaves the second question... now, the question is specifically to Oracle. Technical Root can transform *any* graph to XML. I think there is no tuning that can be done to the Oracle proposal to achive this, because Oracle's proposal tries to do something that is impossible: it tries to add properties to the basic structure to achieve closure *based on examining the metadata*. TechRoot does something else... it works directly with the data in the graph, not with the metadata.

That being the case, what are the reasons for preferring Oracle's algorithm over TechRoot?

Ron

------------------------------------------------------------------------------

Von: Barack, Ron [mailto:ron....@sap.com] Gesendet: Mittwoch, 9. April 2008 00:33 An: sd...@lists.oasis-open.org Betreff: [sdo] Containment discussion Hi Blaise and Xcalia

Two questions...

1. Before we embark on a long discussion of this (or any other) proposal for dealing with containment, I think it's first important to get our use-cases straight. Which use cases are you aiming at here, and why is the functionality provided by issue 66, and in particular the convenience methods based on it, not the best means to deal with it. As I understand your use-case, it seems to fit very well indeed to issue-66.

2. This propoal does not generate a closed XML document from an arbitrary SDO data graph. There are other algorithms that do, for instance, Xcalia's TechnicalRoot proposal. I would think that the main requirement of such an approach to containing is that it can produce XML out of any data graph. What is the advantage of prefering this approach to Technical Root?

Best Regards, Ron