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.