Re: [sdo] Re: Comments on Blaises Proposal

["Blaise Doughan" <blaise.doughan@oracle.com>]



Hi Radu,

 

Let me address your comments regarding #4:

 

[Radu] I think one difficulty that we are going to have is that the proposal actually consists of several distinct proposals rolled into one document. One proposal is changing the meaning of containment,

[Blaise] Hopefully everyone who attended the SDO & DAS face-to-face meetings in Berlin remembers that containment was brought up over and over again as a pain point (by multiple vendors).  The purpose of this document is not to request an arbitrary change to containment, but to address those core concerns to unblock other areas of both the SDO & DAS specifications.

 

[Radu] another is introducing keys into SDO

[Blaise] I do not consider this a large change to SDO.  SDO currently makes use of keys, but does not provide a standard means to determine what the keys are.  In an example taken from page 127 of the SDO specification, the employee type has a key property called "SN" and in the XML representation of a company the non-containment relationship "employeeOfTheMonth" makes use of the employees key property to obtain the value for the foreign key.

 

<sdo:datagraph xmlns:company="company.xsd" xmlns:sdo="commonj.sdo">
    <company:company name="ACME" employeeOfTheMonth="E0002">
        <departments name="Advanced Technologies" location="NY" number="123">
            <employees name="John Jones" SN="E0001"/>
            <employees name="Mary Smith" SN="E0002" manager="true"/>
            <employees name="Jane Doe" SN="E0003"/>
        </departments>
    </company:company>
</sdo:datagraph>

 

Formally identifying properties as keys has the following benefits:

• Making it easier to define SDO metadata from DataObjects.
• Better XML fidelity allowing keys to be derived from the XML schema concept key/keyref and not just ID/IDREF(S)
• Supporting composite keys.  JPA entities and relational databases support composite keys, deriving SDO metadata from these sources will require support for this.

[Radu] and the third (and fourth really) is introducing two new sources of metadata for SDO.

[Blaise]  The intention of the proposal is to not introduce new standard sources of metadata for SDO.  Instead, recognizing that compatibility with DAS is a strong requirement on SDO 3.0, the document demonstrates how making the SDO metadata more flexible can make it easier for DAS implementers to expose the underlying data source metadata as SDO metadata.

 

[Radu] It's going to be difficult to discuss all at the same time.

[Blaise]  Hopefully my above comments simplify the discussion.  Containment is the core problem, keys are related since they are required by the modified algorithms (composite keys can be a later/separate discussion), and finally the relational database and JPA entities examples are meant to supporting arguments for the proposal and not proposals themselves.

-Blaise

 

----- Original Message -----

From: "Radu Preotiuc-Pietro" <radup@bea.com>

To: <sdo@lists.oasis-open.org>

Sent: Tuesday, April 08, 2008 7:01 PM

Subject: RE: [sdo] Re: Comments on Blaises Proposal

Just feeling I needed to chime in; I think my position is very close 
to
Christophe's right now.

1) I too have difficulty reconciling the 
containment concept as
explained in the proposal with bidirectional 
properties. Maybe I need to
spend more time thinking about this.

2) 
BEA also prefers keys as part of the DAS, not SDO

3) This one I won't 
comment on; we need a way to define a data graph and
the present definition 
is concise and served us well until now; but
maybe it's time to change it, 
still we need a concise definition because
it is a key concept

4) 
Agree

I think one difficulty that we are going to have is that the 
proposal
actually consists of several distinct proposals rolled into 
one
document. One proposal is changing the meaning of containment, 
another
is introducing keys into SDO and the third (and fourth really) 
is
introducing two new sources of metadata for SDO. It's going to 
be
difficult to discuss all at the same time.

Radu

On Tue, 
2008-04-08 at 17:25 +0200, Christophe Boutard wrote:
> Hi all,
> 
> Here is the Xcalia point of view about Blaise's proposal.
> 
> According to what I've presented about the "Containment constraint" 
during our F2F meeting, Xcalia logically agrees with Blaise's proposal at almost 
100%.
> 
> The following points are questions about different things 
read in the exchanged emails:
> 
> 1) bidirectional 
containment
> First I'm not sure to understand the concept of 
bidirectional properties with containment=true.  In my opinion it creates a 
kind of cyclic relationship opposed to the containment concept.
> 
> 
2) Keys (identity)
> Concerning the Keys (SDO 3.0 identity chapter - page 
5), I'm not sure that this concept should be defined at the SDO level. For 
instance and based on what I've said during DAS teleconferences I think that the 
Keys are an extra level of metadata that should be applied to an existing SDO 
model for making it persistent through a DAS.
> I'm very interested in 
identifying uses cases for having this Key definition at the SDO level which is 
(IMO) the DTO layer manipulated by DAS which require the Key 
information.
> If there's some real need for having the Keys defined at 
the SDO level, we should set up ASAP a teleconference with both SDO and DAS 
group. In that case I propose to use one the next DAS call for discussing that 
together.
> 
> 3) Containment and composition 
> Concerning 
the discussion about "Composition", I agree that the specification says that "In 
EMOF, the term containment reference is called composite" but I think that 
Blaise's proposal addresses another problem I've described during the F2F. The 
problem is that "containment" plays two roles. The first one is indeed the 
"composition" but the other one has no semantic and is only there for structural 
purposes. The last point is (IMO) the one that should be relaxed and it is the 
reason why I agree with the "Other Specification Changes" chapter (page 5) in 
Blaise's document.
> 4) Is this proposal orthogonal to SDO-66 ?
> I 
think no because the "projection" concept Is very useful for all reason already 
given but I think that Blaise's proposal only concerns the way to deal with only 
one context for users that do not want to project their data model into another 
Typing context. In my opinion it defines a way to serialize non closed data 
graphs.
> If I want to go a little bit further I should say that the 
proposed algorithm could be a specific XMLHelper for a particular 
context.
> Imagine Context1.getXMLHelper() returning an XMLHelper 
compliant with the 2.1 serialization rules which will exclude DOs not reachable 
by containment and another Context2.getXMLHelper() returning a serializer based 
on Blaise's algorithm.
> 
> For summarizing up the Xcalia's position 
we are strongly interested in the proposal and also in discussing the Keys 
(identity) stuff.
> 
> Thanks,
> 
> Christophe 
Boutard
> R&D Team Leader
> Phone: +33 1 56 56 12 58
> 
Fax: +33 1 56 56 12 51
> christophe.boutard@xcalia.com
> 
71 Rue Desnouettes
> 75015 Paris
> www.xcalia.com
> 
> 
> 
> 
> Xcalia provides intermediation software for the agile 
enterprise to easily create transactional composite applications. Using metadata 
and dynamic composition, intermediation enables consistent, configurable and 
unified access to data and services.
>  
> 
> 
> 
> -----Message d'origine-----
> De : Blaise Doughan 
[mailto:blaise.doughan@Oracle.com] 
> Envoyé : mardi 8 avril 2008 
15:45
> À : sdo@lists.oasis-open.org
> Objet : Spam detected by the Fortinet Antispam Re: [sdo] Re: 
Comments on Blaises Proposal
> 
> Hi Frank,
> 
> If the 
definition I'm proposing for containment matches the one in EMOF that 
> 
is great.  Containment is referred to many times in the SDO spec and 
factors 
> into many aspects, so I feel there is value in defining it in 
the SDO spec. 
> If the EMOF definition of composition implies a "part-of" 
relationship in 
> which a bidirectional composition relationship is not 
allowed then my 
> definition is new and different since it would allow 
this.
> 
> You are correct in that the only possible bi-directional 
relationship with 
> containment in both directions is a 1-1. This type of 
relationship is not 
> uncommon in relational databases and is well 
supported by JPA.
> 
> -Blaise
> 
> ----- Original 
Message ----- 
> From: "Frank Budinsky" <frankb@ca.ibm.com>
> To: 
<sdo@lists.oasis-open.org>
> 
Sent: Monday, April 07, 2008 5:14 PM
> Subject: Re: [sdo] Re: Comments on 
Blaises Proposal
> 
> 
> Hi Blaise,
> 
> > 
1.  A clear definition of what containment is:
> 
> I think the 
definition is very clear already. As you pointed out, the spec
> currently 
says that containment is the same as EMOF composition. This is a
> well 
known concept, the same concept as UML bi-value aggregation, as I
> said 
below. Your clarification isn't saying anything new or different.
> 
> > 3.  Allowing both properties involved in a bidirectional 
relationship to
> be containment=true.
> 
> Unless I've missed 
something, this doesn't work for anything but 1-1
> relationships. Assume 
you have A1 with "resident" (containment) references
> to E1 and E2. If 
you also say the E1 to A1 reference ("residence") is a
> containment 
reference, rule #1 is already broken (because E2 is also
> pointing at 
A1).
> 
> What am I missing here?
> 
> Frank.
> 
> 
> 
> 
> "Blaise Doughan" <blaise.doughan@oracle.com>
> 
04/07/2008 11:19 AM
> 
> To
> <sdo@lists.oasis-open.org>
> 
cc
> 
> Subject
> Re: [sdo] Re: Comments on Blaises 
Proposal
> 
> 
> 
> 
> 
> 
> Hi 
Frank,
> 
> My proposal contains small changes with a big 
impact:
> Clear means of deriving metadata from sources such as relational 
databases
> and JPA entities.
> Multiple compatible XML 
representations for SDO DataObjects:  If you
> exposed your DAS 
through a web service you could define your underlying
> model once and 
have per type XML messages (see the proposal for examples
> of 
this).
> Full backwards compatibility.
> 
> What is being 
proposed is the following:
> 
> 1.  A clear definition of what 
containment is:
> "For a property representing a relationship between two 
types A and B,
> then the property is considered containment if instances 
of Type A may not
> share instances of Type B.  In addition Type C 
may have a containment
> relationship to Type B, but an instance of A and 
an instance of C may not
> both reference the same instance of B through 
containment relationships."
> 2.  Removing the restriction that each 
data object must be reachable by
> containment.  This requirement is 
directly related to the XML
> representation and this is why the proposal 
contains a modified algorithm
> for converting DataObjects to XML.
> 
3.  Allowing both properties involved in a bi-directional relationship 
to
> be containment=true.  This is required when deriving metadata 
from sources
> other than XML schema.
> 
> 
> Below are 
my responses to your email:
> 
> [SAP1] How does this differ from 
the UML concept of aggregation.
> [Blaise-08/04/03] I guess this depends 
on your definition of aggregation
> in UML.  The following is the 
important concept:
>     Containment:  
employeeDO1.get("residence") ==
> employeeDO2.get("residence");  // 
This can never be true
>     Non-Containment:  
employeeDO1.get("residence") ==
> employeeDO2.get("residence");  // 
This can be true
> [Frank] My ("the") definition of UML aggregation is "a 
has-a (whole/part)
> relationship".
> [Blaise-08/04/07] My hope was 
to just use a UML word like aggregation or
> composition and found it to 
imprecise.  Martin Fowler once wrote,
> "Aggregation is a part-of 
relationship.  It's like saying that a car has
> an engine and wheels 
as its parts.  This sounds good, but the difficult
> thing is 
considering what the difference is between aggregation and
> 
association".  And according to Martin Fowler, Jim Rumbaugh has the
> 
following to say about aggregation, "Think of it as a modeling placebo".
> 
> [Frank]Aggregations can either be shared (i.e., a part can be used in 
more
> than one aggregations) or exclusive (also known as by-value 
aggregation or
> composition). SDO containment is the latter (exclusive 
aggregation); a
> part can be used in only one aggregation/container - 
which is returned by
> the getContainer() method. Blaise's definition, 
above, seems to be the
> same thing. If so, what exactly is the proposed 
containment change?
> [Blaise-08/04/07] The SDO 2.1 spec does not clearly 
define what a
> containment relationship means.  In section "3.6.3 
Containment" it comes
> close by stating the corresponding term in EMOF is 
called "composite". See
> my proposed definition of containment at the 
beginning of this email.
> 
> [Frank]The only thing that seems 
different (and very strange, in fact) is
> the example of an association 
where both ends have containment=true.
> Allowing this seems to be 
fundamentally at odds with the concept - i.e., a
> part cannot contain its 
whole.
> [Blaise-08/04/07]  According to my definition above both 
ends of a
> containment relationship may have containment=true.  I 
could not find the
> following requirement related to containment in the 
SDO 2.1 specification:
> "a part cannot contain its whole".
> 
> [Frank]How would we know which is the whole and which is the part, 
given
> both can be either according to the metadata?
> 
[Blaise-08/04/07] My proposal includes an example of deriving metadata
> 
from a relational database.  There is a relationship formed between 
the
> EMPLOYEE and ADDRESS tables, since they relate to each other by 
having the
> same primary key values.  In this example we know for 
each employee there
> is a unique address, and for each address there is a 
unique employee.
> There is no way to know which one is the whole and 
which is the part.
> 
> Sounds like you want some new kind of 
bidirectional relationship that says
> one end or the other is 
containment, but the metadata won't say which end.
> Is that it? If so, 
how would the DataObject.getContainer() method work?
> 
[Blaise-08/04/07]  There is no need for a new kind of bidirectional
> 
relationship, my proposal is to allow the opposite property to be a
> 
containment relationship.  getContainer() continues to work as it 
does
> today.  In my particular example for the relationship between 
Employee and
> Address:  getContainer for instances of Employee would 
return an instance
> of Address, and getContainer for instances of Address 
would return an
> instance of Employee:
> DataObject anAddressDO = 
anEmployee.get("residence");
> anAddress == 
anEmployee.getContainer();  // return true
> anEmployee == 
anAddress.getContainer();  // return true
> 
> [Frank]Thanks, 
Frank.
> -Blaise
> 
> 
> ----- Original Message ----- 
> From: "Frank Budinsky" <frankb@ca.ibm.com>
> To: 
<sdo@lists.oasis-open.org>
> 
Sent: Monday, April 07, 2008 12:00 AM
> Subject: Re: [sdo] Re: Comments on 
Blaises Proposal
> 
> Hi Guys,
> 
> I like the proposed 
mapping to XSD for models that don't have containment
> references. 
However, that said, I really don't understand what change is
> being 
proposed for containment here. I think I need a better answer to
> Ron's 
question from below:
> 
> [SAP1] How does this differ from the UML 
concept of aggregation.
> [Blaise] I guess this depends on your definition 
of aggregation in UML.
> The following is the important 
concept:
>     Containment:  
employeeDO1.get("residence") ==
> employeeDO2.get("residence");  // 
This can never be true
>     Non-Containment:  
employeeDO1.get("residence") ==
> employeeDO2.get("residence");  // 
This can be true
> [Frank] My ("the") definition of UML aggregation is "a 
has-a (whole/part)
> relationship". Aggregations can either be shared 
(i.e., a part can be used
> 
> in more than one aggregations) or 
exclusive (also known as by-value
> aggregation or composition). SDO 
containment is the latter (exclusive
> aggregation); a part can be used in 
only one aggregation/container - which
> 
> is returned by the 
getContainer() method. Blaise's definition, above,
> seems to be the same 
thing. If so, what exactly is the proposed
> containment change? The only 
thing that seems different (and very strange,
> 
> in fact) is the 
example of an association where both ends have
> containment=true. 
Allowing this seems to be fundamentally at odds with the
> 
> 
concept - i.e., a part cannot contain its whole. How would we know which
> 
is the whole and which is the part, given both can be either according 
to
> the metadata? Sounds like you want some new kind of 
bidirectional
> relationship that says one end or the other is 
containment, but the
> metadata won't say which end. Is that it? If so, 
how would the
> DataObject.getContainer() method work?
> Thanks, 
Frank.
> 
> 
> 
> 
> "Blaise Doughan" 
<blaise.doughan@oracle.com>
> 
04/04/2008 11:14 AM
> 
> To
> <sdo@lists.oasis-open.org>
> 
cc
> 
> Subject
> [sdo] Re: Comments on Blaises 
Proposal
> 
> 
> 
> 
> 
> 
> Hello 
All,
> 
> I think this is going to turn out to be a very good 
discussion on
> containment :),
> 
> 
> There are some 
points in the proposal I would like to draw attention to:
> 
> 1. 
Full Backwards Compatibility
> A number of TC members have made strong 
cases for backwards compatibility
> and my proposal supports this.  A 
user defining SDO 2.1 compatible
> metadata will not see any change in 
behaviour wrt my proposed changes.
> 
> 2.  Relaxed Containment 
Requirements
> The proposal allows for a data graph to have no containment 
relationships.
> 
>  This reflects the case where SDO metadata 
is derived from unannotated
> Java classes/interfaces.  Since XML 
handling is a core part of the spec
> (XMLHelper, XSDHelper, DataObject 
serialization), the proposal provides an
> 
> algorithm to keep 
these concepts valid.  Ron has pointed out that the
> algorithm can 
fail, but it fails in the same way as all other XML binding
> tools.  
The alternative is to not allow the XML serialization of
> DataObjects 
without all the necessary containment which is difficult to
> determine 
and is unnecessarily restrictive.
> 
> 3.  DAS
> The 
proposal contains an example of deriving SDO metadata from a
> relational 
database.  XML schemas are then derived wrt different SDO
> 
types.  I am excited about the idea that the data source metadata could 
be
> 
> defined once, and then per type XML messages (one for 
findAddress, another
> 
> for findEmployee) could be used each of 
which reflects the core metadata.
> 
> 
> Below are my 
responses to the points raised by Ron's email:
> 
> [Ron] Much as I 
like aspects of this proposal, there are several
> fundamental problems 
with it.  In particular, Blaise's claim that "makes
> use of 
containment properties when they are present and handles things
> when 
they are not" is false.  The fundemtental problem is that what 
Blaise
> 
> calls "orphans" can not be determined by analysing the 
metadata, you have
> to look at the actual instances.  Using the 
proposed algorithm, it is
> still possible to generate documents with 
unresolved references.
> [Blaise] I do not believe the claim is 
false.  Solving the object-to-XML
> impedance mismatch requires that 
each object be reachable by containment,
> the onus is always on the user 
to ensure enough containment relationships
> are in place (this is true in 
both SDO 2.1 and JAXB 2.0).  The algorithm
> could prevent all broken 
references by allowing remaining orphan instances
> 
> to be adopted 
by the complex type corresponding to the root type.  The
> algorithm 
borrows from the "technical root" originally proposed by Xcalia,
> 
> but instead of requiring an additional object, the algorithm gives a 
place
> 
> for non-contained data to go.
> 
> [Ron] I 
want to point out that this, or any other proposal regarding
> containment 
within a context is somewhat orthogonal to the issue 66. Issue
> 
> 
66 solves the more general problem of moving data between contexts in
> 
which the definition of the types varies slightly.  Both containment 
and
> instance class are our first targets, but certainly we believe this 
to be
> a a way in which other problems, such as versioning, can be 
addressed.
> 
> [Ron] Nonetheless, let's compare, at a very high 
level, the approach to
> containment of the two approaches.
> 
> [Ron] One of the problems we've got when dealing with different
> 
application using different sources of metadata is that the definition
> 
have to sync-up.  In standard SDO 2.1, metadata comes basically from 
XSD.
> The standard defines how to convert this to Java, and it's expected 
that
> the users of the java interfaces take what they get.
> 
> [Ron]Blaise's proposal at least allows a second route.  It allows 
the data
> 
> to be defined from Java, and any XML clients have to 
take what they get.
> [Blaise] My proposal involves a reinterpretation of 
what containment
> means.  In SDO 2.1 containment represented a 
nested relationship between
> DataObjects.  A DataObject of Type A 
can be nested within a DataObject of
> Type B in the resulting XML if an 
instance of Type A cannot be shared
> between instances of Type B.  
Containment in SDO 3.0 should not simply
> represent nesting, but the 
underlying concept that enables nesting.  This
> does not simply 
allow a "second route", but makes it easier to derive an
> SDO metadata 
from multiple sources.  It is more useful for containment to
> model 
the data sharing rules from a relational database or JPA entities,
> then 
to be an artificial mapping of these sources to an XML schema.
> 
> 
[Ron]That we've tried to achieve with Issue 66 is to 
"meet-in-the-middle".
> 
>  That is, for instance, some aspects 
of the model can be defined in Java,
> the things that effect XML can be 
defined in XSD.  Both sides can be kept
> a little happy.
> 
[Blaise]  The issue 66 proposal works well when the SDO model being
> 
projected has no containment relationships and is projected into a 
context
> 
> with containment relationships.  This is a well 
proven approach
> demonstrated by technologies such as JAXB and JPA.  
It becomes more
> difficult when projecting a model with containment to a 
model with
> containment.
> 
> [Ron]In other words, the 
project method allows the XML structure to be
> added in after the 
Properties are already defined, without touching the
> application that is 
defining the properties.  None the less, the XML
> client has a large 
degree of flexibility in defining the document he
> wants.
> 
[Blaise] A common TopLink/EclipseLink use case is the following.  A
> 
programmer is creating an application to access relational data and 
expose
> 
> it as a web service (XML).  They create an object 
model and apply JPA
> metadata in the form of annotations to map the 
objects to the database.
> Now in order to map these same objects to XML 
the user needs to apply JAXB
> 
> annotations.  When I do this 
I always look at the JPA annotations to find
> out the data sharing rules 
so I can apply containment/nesting
> relationships.  There are N ways 
to map an object model to an XML schema,
> when I take into account the 
data sharing rules from the JPA annotations
> there are always <N ways 
to map the annotated object model to an XML
> schema.  If SDO 
metadata evolves to represent real relationships between
> data it can 
ease the transition from one form to another.
> 
> 
> 
[Ron]Please find my detailed comments to Blaise's proposal in the 
attached
> 
> document.
> 
> 
> Best 
Regards,
> Ron
> 
> 
> Responses to document 
comments:
> 
> [SAP1] How does this differ from the UML concept of 
aggregation.
> [Blaise] I guess this depends on your definition of 
aggregation in UML.
> The following is the important 
concept:
>     Containment:  
employeeDO1.get("residence") ==
> employeeDO2.get("residence");  // 
This can never be true
>     Non-Containment:  
employeeDO1.get("residence") ==
> employeeDO2.get("residence");  // 
This can be true
> 
> [SAP2] Address has ?eId?, is that because 
there is a 1:1 relationship
> between employee and address.  But if 
that?s the case, I wouldn?t expect
> an SDO representation to give them 
both keys, the reference to the ?main?
> object should be enough?
> 
[Blaise] The domain model used in this example was derived from a
> 
relational database so I brought in all the primary keys.  If Address 
is
> never used as a root type, and is only referenced through 
containment
> relationships then it would not need an ID (to satisfy 
SDO).
> 
> [SAP3[You have a bi-directional relationship, that is 
containment in both
> directions.  In 2.1 this is not allowed (since 
it would result in an
> endless loop when serializing).  How would we 
ever find the ?root? of a
> datagraph?  Would we have to check for 
cycles?
> [Blaise] When generating an XML schema if the value of 
containment
> property is being converted then the property representing 
the back
> pointer to the parent must not generate an XML element.  
Instead the XML
> schema should be annotated to indicate that this 
relationship exists.
> 
> [SAP4]Wouldn?t it be possible to take the 
document structure you define
> later and apply it here?  What would 
be the effect?  Would this be
> equivalent to the transitive 
closure?  I?m asking because when we?re
> coming from unannotated 
classes, there is default no containment, and
> therefore no meaningful 
change summary.  It would be good if we could
> apply your algorithm 
to solve this problem.
> [Blaise]If the scope of ChangeSummary was changed 
from containment to the
> datagraph itself then the document structure in 
the document would apply.
> 
> [SAP5]I like this.  But it?s 
rather besides the point for the containment
> proposal, isn?t it.  
Unless you require that all non-containment
> properties have keys, which 
you?re not doing, right?
> [Blaise] It is not the non-containment 
properties that keys but their
> values.  This is particulary useful 
for SDO Types with composite keys.
> 
> [SAP6]It?s interesting that 
you have non-containment as the default case,
> exactly the opposite of 
what JAXB does.  How does this proposal relate to
> the topic of JAXB 
alignment.  Are we defining new annotations?
> [Blaise] For the 
purpose of this document I kept the annotations strongly
> linked to the 
Property metadata.  Since Property had a property called
> 
"containment" I introduced an annotation called "Containment".  The
> 
specifics of the annotations can be worked out as part of a seperate
> 
discussion.
> 
> [SAP7]In your definition of containment, Address is 
exclusively owned by
> employee, right?
> [Blaise] Yes see my 
response to [SAP2].
> 
> [SAP8]In your example the traversal path is 
always clear, but I don?t
> believe this is generally true.  
Especially if we are coming from Java
> interfaces, where the order of the 
properties is undefined.
> [Blaise] The order of properties is unrelated 
to the traversal path.
> 
> [SAP9]I believe there is a conceptual 
problem here.  It is not Types that
> are ?orphaned?, but 
objects.  A type could still have some containment
> relationship to 
another type, but instances of that type used someplace
> else, in a 
non-containment relationship.
> [Blaise] In the SDO Type to XML Schema 
algorithm containment relationships
> 
> in SDO translate to nesting 
relationships in XML schema.  As such types
> can definitely be 
orphaned, the solution to this is to have the complex
> type corresponding 
to the root type "adopt them"  although this
> relationship is 
represented in the XML schema it is never realized as a
> property on the 
root type.  Instances can also be orphaned, the algorithm
> makes the 
same assumption as SDO 2.1 and JAXB that all the necessary
> containment 
relationships are in place, if this is not sufficient then the
> 
> 
root complex type will need to be adapted to always expect orphans.
> 
> [SAP10]I?m trying to imagine your use-case.  Is it something like 
this?
> You have something like a DAS with methods like 
getAddress(),
> getEmployee(), etc.  And even though the SDO 
representation of the results
> 
> are the same, you want to have a 
different schemas for each result type.
> Is that correct?  This is 
an extremely cool idea!
> [Blaise] That is the exact use case we have in 
mind. The core data model
> is derived from the data source, then data is 
requested based on a
> particular SDO type.  The XML representation 
of this data should have the
> queried type as the root type.
> 
> [SAP11]Traversal path is not sufficiently defined.  It seems to 
mean, if
> I?ve already seen the type, I don?t generate the element.  
Is this right?
> In your examples, every time a reference is thrown out 
based on this rule
> it happens to be the back-pointer to a containment 
relation.  I agree that
> 
> in this case, we can throw the 
data out of the XML.  However, this does
> not hold in 
general.
> [Blaise] If the SDO type has already been seen and an XML 
complex type has
> 
> already been generated then don't generate 
another XML complex type for
> it.  When converting properties to 
elements then if the property is
> containment create a nested element, 
otherwise create an element
> representing a FK.
> 
> Imagine 
a node that has a containment relationship to itself (say,
> 
Person.children).  That?s of course, a trivial example, but you could 
have
> 
> more complex models, where this would be impossible to 
analyse.
> [Blaise]Not sure if the answer to the above point addresses 
this, but a
> SDO type can have a containment property of the same type as 
the owning
> type.
> 
> I think this algorithm makes the 
fundamental mistake of thinking that
> containment is a feature of the 
metadata, where it?s really a part of the
> data.
> [Blaise]  
Can you comment further on containment being part of the data?
> 
> 
See also the following comments.
> [SAP12]Lets imagine adding ?Department? 
to this model.  Department has a
> relationship to Employee, and has 
a non-containement relationship to
> address.
> The type ?Address? 
won?t be an orphan, but the XML would contain
> unresolved 
references.
> [Blaise] See my response to [SAP13]
> 
> Maybe 
there should be a property ?orphans? that has type ?Object?, rather
> than 
a set of elements?
> [Blaise] During the marshalling process "orphans" can 
be determined, there
> 
> is no need to explicity track them as a 
property value.  Also the orphans
> change depending on the type of 
the root object.
> 
> [SAP13]Same problem.  In a general case, 
the list of employees that is
> property of this object might not be the 
complete list that you want to
> have in your orphans.  In such 
cases, this  is broken.
> [Blaise]  This algorithm does make the 
assumption that if there are
> containment relationships defined for a SDO 
type then they will hold all
> the instances that will be referenced by 
non-containment relationships.
> This is assumption is also made by SDO 
2.1 and JAXB 2.0.  This assumption
> could be removed by adding 
elements to the root complex type to hold onto
> all orphaned 
instances.
> 
> [SAP14]How do we know when to apply this algorithm, 
and when to apply the
> algorithm specified in SDO 2.1?  I think 
there might be backwards
> compatibility issues here.  Maybe we need 
a flag to determine this.
> [Blaise] I do not see the algorithm specified 
here as being a second
> algorithm.  Instead it is an ammendment to 
the 2.1 algorithm.  When
> converting SDO 2.1 compliant metadata to 
XML schema the algorithm will
> produce the same XML schema.  Of 
course the algorithm also supports the
> proposed metadata.
> 
> 
>  -Blaise
> 
> ----- Original Message ----- 
> From: "Barack, Ron" <ron.barack@sap.com>
> To: 
<blaise.doughan@oracle.com>; 
<sdo@lists.oasis-open.org>
> 
Sent: Thursday, April 03, 2008 6:22 PM
> Subject: Comments on Blaises 
Proposal
> 
> Hi Everyone,
> 
> Much as I like aspects 
of this proposal, there are several fundamental
> problems with it.  
In particular, Blaise's claim that "makes use of
> containment properties 
when they are present and handles things when they
> are not" is 
false.  The fundemtental problem is that what Blaise calls
> 
"orphans" can not be determined by analysing the metadata, you have to
> 
look at the actual instances.  Using the proposed algorithm, it is 
still
> possible to generate documents with unresolved references.
> 
> I want to point out that this, or any other proposal regarding 
containment
> 
> within a context is somewhat orthogonal to the 
issue 66.  Issue 66 solves
> the more general problem of moving data 
between contexts in which the
> definition of the types varies 
slightly.  Both containment and instance
> class are our first 
targets, but certainly we believe this to be a a way
> in which other 
problems, such as versioning, can be addressed.
> 
> Nonetheless, 
let's compare, at a very high level, the approach to
> containment of the 
two approaches.
> 
> One of the problems we've got when dealing with 
different application
> using different sources of metadata is that the 
definition have to
> sync-up.  In standard SDO 2.1, metadata comes 
basically from XSD.  The
> standard defines how to convert this to 
Java, and it's expected that the
> users of the java interfaces take what 
they get.
> 
> Blaise's proposal at least allows a second 
route.  It allows the data to
> be defined from Java, and any XML 
clients have to take what they get.
> 
> That we've tried to achieve 
with Issue 66 is to "meet-in-the-middle". That
> 
> is, for 
instance, some aspects of the model can be defined in Java, the
> things 
that effect XML can be defined in XSD.  Both sides can be kept a
> 
little happy.
> 
> In other words, the project method allows the XML 
structure to be added in
> 
> after the Properties are already 
defined, without touching the application
> 
> that is defining the 
properties.  None the less, the XML client has a
> large degree of 
flexibility in defining the document he wants.
> 
> Please find my 
detailed comments to Blaise's proposal in the attached
> document.
> 
> 
> Best Regards,
> Ron
> 
> 
> 
-----Ursprüngliche Nachricht-----
> Von: blaise.doughan@oracle.com 
[mailto:blaise.doughan@oracle.com]
> Gesendet: Donnerstag, 3. April 2008 
22:05
> An: sdo@lists.oasis-open.org
> Betreff: [sdo] Groups - Proposal - Containment and Enterprise Data 
Models
> (SDO-EnterpriseDataModel.doc) uploaded
> 
> This is 
the containment proposal I mentioned during the conference call on
> April 
1, 2008.
> 
>  -- Mr. Blaise Doughan
> 
> The 
document named Proposal - Containment and Enterprise Data Models
> 
(SDO-EnterpriseDataModel.doc) has been submitted by Mr. Blaise Doughan 
to
> the OASIS Service Data Objects (SDO) TC document repository.
> 
> Document Description:
> The SDO spec to date has primarily 
concerned itself with deriving SDO
> metadata from XML schema.  As 
such containment has come to represent the
> concept of nesting as it 
relates to XML elements.  We prefer to think of
> containment as a 
type of "privately owned" concept.  For the association
> "residence" 
between types "Employee" and "Address" if instances of
> "Employee" may 
not share references to instances of "Address" then it is a
> containment 
relationship:
> 
> Containment:  employeeDO1.get("residence") 
==
> employeeDO2.get("residence");
>  // This can never be 
true
> Non-Containment:  employeeDO1.get("residence") ==
> 
employeeDO2.get("residence");  // This can be true
> 
> Using 
the above interpretation of containment it becomes easy to derive
> 
SDO
> metadata from other sources, such as JPA entities, JAXB 
objects,
> relational
> databases, etc. (the doc provides an example 
of deriving SDO metadata from
> a relational database).  These 
sources may not have a concept of nesting,
> but they are aware of data 
sharing rules.  Of course DataObjects require
> an
> XML 
representation, and containment has been an important part of that.
> The 
attached proposal contains an algorithm that makes use of containment
> 
properties when they are present and handles things when they are not.
> 
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/sdo/document.php?document_id=27848
> 
> 
> 
> Download Document:
> 
http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/27848/SDO-EnterpriseDataModel.doc
> 
> 
> 
> 
> PLEASE NOTE:  If 
the above links do not work for you, your email
> application
> may 
be breaking the link into two pieces.  You may be able to copy and
> 
paste
> the entire link address into the address field of your web 
browser.
> 
> -OASIS Open Administration
> 
> 
> 
---------------------------------------------------------------------
> 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
> 
> 
> 
> 
---------------------------------------------------------------------
> 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
> 
> 
> 
> 
---------------------------------------------------------------------
> 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 
> 
> 
> 
---------------------------------------------------------------------
> 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.

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