sdo message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sdo] Re: Comments on Blaises Proposal
- From: "Blaise Doughan" <blaise.doughan@oracle.com>
- To: <sdo@lists.oasis-open.org>
- Date: Wed, 9 Apr 2008 16:52:39 -0400
Hi Frank.
To be clear my proposal asks that the following
existing API all be allowed to return true wrt the example model:
employeeType.getProperty("residence").isContainment() ==
true;
employeeType.getProperty("residence").getOpposite().isContainment() ==
true;
addressType.getProperty("resident").isContainment()
== true;
addressType.getProperty("resident").getOpposite().isContainment() ==
true;
The above truly reflects the data sharing
rules. The data sharing rules are very useful for determing how data can
be written to XML, I will demonstrate with the following examples.
Example #1
We all agree on employee having a containment
relationship to address.
X --containment--> EMPLOYEE
--containment--> ADDRESS
<x>
<employee>
<address>...</address>
</employee>
</x>
Example #2
My proposal allows the opposite
property from Address to Employee to also be containment. Again
containment refers to the data sharing rules. Using the data sharing rules
an Address object can be marshalled as follows.
Y --containment--> ADDRESS --containment -->
EMPLOYEE
<y>
<address>
<employee>...</employee>
</address>
</y>
Example #3
Your argument is that the Address type can not have
the opposite property to Employee be containment. With this restriction in
the resulting XML employee data could not be nested within address data.
This also forces employee to have a key that address can make use of to
represent the non-containment relationship.
Y --containment--> ADDRESS --non-containment
--> EMPLOYEE
<y>
<address
employee="1">...</address>
<employee
id="1">...</employee>
</y>
The reason I am proposing that a property and its
opposite property can be containment is because it reflects the data sharing
rules. Data sharing rules are useful because they allow a better XML
representation. Example #2 is better than example #3 (as
example #3 requires a key that truly isn't necessary).
-Blaise
----- Original Message -----
Sent: Tuesday, April 08, 2008 9:14 PM
Subject: Re: [sdo] Re: Comments on Blaises
Proposal
Hi Blaise,
You said:
> In the relational database
example two tables that related to one
another because the primary key is
also the foreign key would result in a
bidirectional containment
relationship.
Absolutely, I agree, but a bidirectional containment
relationship is a
containment reference in only one direction. The inverse
of the
containment reference is NOT also a containment reference, it's an
explicit (named) "container" reference. Looking at your EMPLOYEE and
ADDRESS tables, it seems clear to me that the containment reference is
from Employee to Address. The ADDRESS table has a FK to the EMPLOYEE table
which says there is a 1-1 relationship where ADDRESSES can't exist without
a corresponding EMPLOYEE. Therefore, Employees would own Addresses in the
logical model. The "residence" containment reference is exactly what I
would expect, and that's even what you say on page 20. Now, I understand
that you can take this a step further (especially when you bring JPA into
the picture) to say that the logical model's reference is bidirectional
with an explicit inverse named "resident". But, that should be the end of
story - you've defined a bidirectional containment reference. What I don't
understand is why you need to take this a step further and also say that
you need a new kind of special relationship where both ends are
containment - "bi-containment" as opposed to "bi-directional containment".
That's the part I just don't understand, and it sounds like maybe others
are also confused by?
Frank
"Blaise Doughan"
<blaise.doughan@oracle.com>
04/08/2008 05:02 PM
To
<sdo@lists.oasis-open.org>
cc
Subject
Re: [sdo] Re: Comments on Blaises
Proposal
Hi Frank,
The proposal is based
on the premise that it is a worthy endeavor to
derive SDO metadata from
sources like (relational databases and JPA
entities) in addition to XML
schema. At this point I'm not 100% sure we
agree on this premise.
My document demonstrates that bi-directional containment
relationships
exist in the world (atleast in relational databases and JPA),
as such the
proposal introduces bi-directional containment to SDO.
I have responded to your points below:
[Frank]The
EMOF definition is exactly the same except for the part about
bidirectional
composition, which I think is conceptual nonsense and needs
to be removed
from the proposal.
[Blaise] I do not agree that SDO containment equals the
EMOF definition of
composition. In my examples I have demonstrated
that containment relates
to things like the JPA OneToOne and OneToMany
mappings. The JPA OneToOne
mapping is allowed to be bidirectional and
is very useful. I have also
demonstrated that the underlying database
structure represents
bi-directional containment. We can continue to
debate the definition, but
I am more interested in what metadata you would
like to see derived from
the examples I've provided in my
proposal.
As soon as you allow containment on both
ends of an
association, you're guaranteeing containment cycles. By
definition,
A1.getContainer().getContainer() == A1. Are you proposing that
we remove
the restriction about containment cycles?
[Blaise] Cycles between two
objects should be allowed.
[Frank]Assuming A1 references
E1,
what would A1.getRootObject() return - A1 or E1? What about
E1.getRootObject()? Why would introducing this kind of complexity be good
for SDO?
[Blaise] Assuming a bi-directional containment relationship
between A1 and
E1, then E1.getRootObject() would return A1, and
A1.getRootObject() would
return E1. The benefit for SDO would be to
represent metadata that came
from sources other that XML Schema. Also
the ability to generate per type
XML messages (That all conform to the same
data sharing rules). Again
assuming that it is a worth while goal to
generate SDO metadata from
sources like relational databases and JPA
entities (useful for a DAS),
what metadata would you like to see
generated? Note that metadata derived
from XML schema would not result
in any containment cycles.
[Frank]All this aside, I can't even see what
criteria one would use for
deciding
to define such an association.
[Blaise] There are two examples in the document that demonstrate when this
applies. In the relational database example two tables that related to
one another because the primary key is also the foreign key would result
in a bidirectional containment relationship. Also in the JPA entity
example a bidirectional OneToOne relationship results in a bidirectional
containment relationship in SDO.
In fact, it seems to me that
your algorithm
would produce the same results if only the residence
reference was
containment (i.e., resident was non-containment). Your step #6
seems to be
the key. Couldn't a slightly different version of step #5
even do the same
thing if neither end of the association were
containment, that is, if you
say that 1-1 non-containment references to
orphans should serialize in
place? Even as it is, I think the algorithm
would produce resonable
serializations, even if the residence-resident
association was completely
non-containment.
[Blaise] It may be confusing
because the object model is shallow and the
complex type for the root type
is converting the reference relationships
to nested relationships, adding
another object to the model might make
things clearer.
[Frank]
I really can't see why we need to invent a new modeling
concept
(bidirectional composition) for SDO - that would seem pretty
extreme to
me.
[Blaise] I do not see the extreme aspect to this proposal. None of
the
APIs change, it simply allows the back pointer of a containment
relationship to be containment. It's not a new modeling concept (JPA
has
this), it's just new to SDO.
-Blaise
----- Original
Message -----
From: "Frank Budinsky" <frankb@ca.ibm.com>
To:
<sdo@lists.oasis-open.org>
Sent:
Tuesday, April 08, 2008 3:51 PM
Subject: Re: [sdo] Re: Comments on Blaises
Proposal
Hi Blaise,
The EMOF definition is exactly the same except
for the part about
bidirectional composition, which I think is conceptual
nonsense and needs
to be removed from the proposal. As soon as you allow
containment on both
ends of an association, you're guaranteeing containment
cycles. By
definition, A1.getContainer().getContainer() == A1. Are you
proposing that
we remove the restriction about containment cycles?
Assuming A1 references
E1, what would A1.getRootObject() return - A1 or
E1? What about
E1.getRootObject()? Why would introducing this kind of
complexity be good
for SDO?
All this aside, I can't even see what
criteria one would use for deciding
to define such an association. In fact,
it seems to me that your algorithm
would produce the same results if
only the residence reference was
containment (i.e., resident was
non-containment). Your step #6 seems to be
the key. Couldn't a slightly
different version of step #5 even do the same
thing if neither end of
the association were containment, that is, if you
say that 1-1
non-containment references to orphans should serialize in
place? Even as it
is, I think the algorithm would produce resonable
serializations, even if
the residence-resident association was completely
non-containment. I really
can't see why we need to invent a new modeling
concept (bidirectional
composition) for SDO - that would seem pretty
extreme to
me.
Frank
"Blaise Doughan" <blaise.doughan@Oracle.com>
04/08/2008 09:45 AM
To
<sdo@lists.oasis-open.org>
cc
Subject
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
---------------------------------------------------------------------
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]