Hello Radu,
I will address your points below:
[Radu] I generally like the TechnicalRoot proposal, but one thing that
bothers me is the relationship with datagraph. If I understand
correctly, <datagraph> will be a child of <technicalRoot>,
so there will be two levels of indirection before getting to the data.
In addition, we'll have to have some generic Schema for
<technicalRoot>. That's not bad in and of itself, but it would be
much more elegant if <technicalRoot> and <datagraph> were
the same. I understand that because DataGraph is a "user-visible"
DataObject, this would not work very well, but consider this: we
started off (in SDO 2.0.1) with one special-behavior container
(DataGraph) and now we end up with one special-behavior (what I mean by
special-behavior is that it acquires containment references at
serialization time without them being set at any point) container
(TechnicalRoot) and one normal-beahvior container (DataGraph). Having
the normal-DataObject DataGraph seems redundant at this point.
[Blaise] I agree with you here, TechnicalRoot may be a better DataGraph.
[Radu] As for the per-message type use-case presented by
Blaise, I acknowledge that it is a good use-case. I am not sure however
that Oracle's proposal for SDO-124 does enough really. It just creates
one alternative Schema for one particular relationship.\
[Radu] This assumes that there is something wrong with:
[Radu] <address e-id="2" street="1 A St." city="A
City"/>
[Blaise] There is something wrong with the above
doc since it has broken references. If the e-id attribute is of type
xs:IDREF then this document fragment would not validate since there is
no corresponding value on a node of type xs:ID.
[Radu] But there is nothing wrong with just specifying the
emp-id without having the employee in-line.
Or the user may want this:
[Radu] <address e-id="2" resident-name="Jane" street="1 A
St." city="A City"/>
[Radu] i.e. collapsing the employee info and address info in
the same structure; perfectly reasonable.
Or why not this:
[Radu] <employee e-id="2" name="Jane" street="1 A St."
city="A City" department-name="Finance"/>
[Radu] The version presented in the document
[Radu] <address e-id="2" street="1 A St." city="A City">
<resident e-id="2" name="Jane/>
</address>
[Radu] is one of several that are reasonable.
[Blaise] I agree that many XML representations
are possible for representing types. SDO currently has one way,
SDO-124 builds on that. I would be in favour of SDO 3.0 supporting
meet in the middle mapping (the TopLink/EclipseLink SDO implementation
can do this), but this has not been addressed by any of the containment
proposals.
[Radu] So I am thinking that SDO may not be the place to
solve the problem and a higher-level mechanism (DAS?) is needed which
may involve letting the user define relationships between different
sets of SDO metadata/DAS operations.
[Blaise] So your position is that there should be
a separate set of types to represent each message, or that DAS
operations would not share types?
-Blaise
Radu Preotiuc-Pietro wrote:
BF6B6CA032BA0A429BD924F96765147DBF2E8A@repbex02.amer.bea.com"
type="cite">
I generally like the
TechnicalRoot proposal, but one thing that bothers me is the
relationship with datagraph. If I understand correctly,
<datagraph> will be a child of <technicalRoot>, so there
will be two levels of indirection before getting to the data. In
addition, we'll have to have some generic Schema for
<technicalRoot>. That's not bad in and of itself, but it would be
much more elegant if <technicalRoot> and <datagraph> were
the same. I understand that because DataGraph is a "user-visible"
DataObject, this would not work very well, but consider this: we
started off (in SDO 2.0.1) with one special-behavior container
(DataGraph) and now we end up with one special-behavior (what I mean by
special-behavior is that it acquires containment references at
serialization time without them being set at any point) container
(TechnicalRoot) and one normal-beahvior container (DataGraph). Having
the normal-DataObject DataGraph seems redundant at this point.
As for the per-message type use-case presented
by Blaise, I acknowledge that it is a good use-case. I am not sure
however that Oracle's proposal for SDO-124 does enough really. It just
creates one alternative Schema for one particular relationship.
This assumes that there is something wrong with:
<address e-id="2" street="1 A St." city="A
City"/>
But there is nothing wrong with just specifying
the emp-id without having the employee in-line.
Or the user may want this:
<address e-id="2" resident-name="Jane"
street="1 A St." city="A City"/>
i.e. collapsing the employee info and address
info in the same structure; perfectly reasonable.
Or why not this:
<employee e-id="2" name="Jane" street="1 A
St." city="A City" department-name="Finance"/>
The version presented in the document
<address e-id="2" street="1 A St." city="A
City">
<resident e-id="2" name="Jane/>
</address>
is one of several that are reasonable.
So I am thinking that SDO may not be the place
to solve the problem and a higher-level mechanism (DAS?) is needed
which may involve letting the user define relationships between
different sets of SDO metadata/DAS operations.
Radu
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:
9279AFBA5302884AB7169C4C51B6FDF7F5FE95@dewdfe1a.wdf.sap.corp"
type="cite">
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
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
---------------------------------------------------------------------
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
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.