Re: [sdo] Re: Comments on Blaises Proposal

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

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