OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: TR: [sdo] Containment discussion


Hi,

Due to OASIS membership issues, Xcalia members are temporarily unable
to post messages on the SDO3 mailing list (and also unable to use
their @xcalia.com on the SDO comment mailing list).
Here the reply to the last mail from Blaise we've received.

Thanks and sorry for the inconvenience,

--François

De : François Huaulmé
Envoyé : jeudi 24 avril 2008 15:18
À : sdo@lists.oasis-open.org
Objet : RE: [sdo] Containment discussion

Hi,

Here are some thoughts following last Blaise's mail. First, I'd like
to ensure we're all talking about the same use case:
•	Containment is EMOF/UML aggregation
•	We have 2 types: A and B.
•	We have a "A –contains-> B" relationship
•	We'd like to see an instance of B (B1) as the "root" element of the
serialized datagraph.
•	B1 is contained by an instance of A (A1).

In this use case, B1 needs A1 somewhere in the serialized datagraph.
Speaking from a DAS point of view, B1 might not have any "identity"
but its container (A1). If a DAS wants to update values of B1, it
needs A1 because there might be no way to find B1 without its
container, A1.

A simple way to express aggregation using XML is to nest the
aggregated object/elements as children of another element/object. So,
if I follow the Oracle's proposal and if I start from B1 then I'll get
a XML that would look like this:

<B name="B1">
                <A name="A1"></A>
</B>

The generated schema will inform that the nested A1 is the actual
container of B1 using a "sdo:oppositeProperty" (Blaise: I'm having
trouble with the Oasis web site so I could not download the last
version of your proposal… so please correct me if I'm wrong).

Blaise, you said "Here we are sending a message that may or may not be
received by an SDO client.". If a non-SDO client (e.g. a client not
able to understand the sdo:oppositeProperty) receive this XML
document, I am wondering how this client will be able to get a sense
that A1 is the actual container of B1 (if A1 is contained by B1
element in the XML document).
In the current version of technical root, I would agree that it seems
hard to use B1 as the "root" of the datagraph. But technical root only
fails here because we're trying to serialize an object that has a
container. If a B instance is created without any container, it can
(hopefully ) be serialized to XML.

Now, more generally speaking, if containment is used as aggregation,
does it make sense to use a contained object as root object of the
datagraph? Again, from an Xcalia point of view, a contained object
might have no existence without its container and the XML structure
directly reflects the Container/Contained relationship.

Thanks,

François.


De : Blaise Doughan [mailto:blaise.doughan@oracle.com]
Envoyé : mercredi 23 avril 2008 18:10
À : sdo@lists.oasis-open.org
Objet : Spam detected by the Fortinet Antispam Re: AW: [sdo]
Containment discussion

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.barack@sap.com]
Gesendet: Mittwoch, 9. April 2008 00:33
An: sdo@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




---------------------------------------------------------------------
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]