Hi
Regarding the TechRoot/ DataGraph discussion, I really
wouldn't want to move in the direction of making DataGraph special
again. One approach could be to borrow the @sdo:orphans annotation, and
say that getters on a property with this annotation return a list of all
referenced objects that are not part of the containment tree. The property
would have to be multivalued, and not have a data type, and we could "filter"
the non-contained objects based on the type of the property.
Of course, the property serializes to XML just as if there
were "real" containment there. The property would have to be
read-only (no setter). This approach is consistent with the way
ChangeSummary is handled, and has the special advantage of removing the need to
define {commonj.sdo}TechnicalRoot.
Ron
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.