Hi Blaise,
everyone,
Answers
inline
[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] Well, then we have this problem
already because employees have references to departments and those are going
to be broken if we serialize just the employee-address combination, because
employees don't contain departments.
[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?
[Radu] I think that in plenty of cases DAS operations will share types.
My point was that in the cases when users want per-message type, IMO they will
want more flexibility to decide what this message-type is.
-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.
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. |