[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] Re: Comments on Blaises Proposal
Hi Everyone,
Radu writes:
I definitely remember containment being mentioned as one of the pain
points. But what I also remember is a couple of use-cases being brought
up in support of that assertion:
1) the desire to "SDO-ize" arbitrary/annotated POJOs so that SDO
metadata introspection and SDO dynamic APIs can be used in an
application that formerly only dealt with POJOs;
2) make it possible to also potentially generate change summary for
POJOs "under the covers" thus opening up a new kind of clients for the
DASNeither this nor Issue 66 is really addressing the above 2 points that
were raised at the F2F. I have made a proposal on this mailing list a
while ago that does address them based on the idea that containment
information is always present for the situations where it is needed, but
in situation where it is in the way it can be ignored. I will upload the
proposal to the OASIS site, to make it easier to reference it.
We are getting there, one step at a time. It was a decision of the TC to discuss the project method only between data objects, not from pojo to data object. In accepting the proposal as is, we made a giant step in this direction.
The next step is now to work on resolving Issue 5 (see my earlier proposal)
-----Ursprüngliche Nachricht-----
Von: Radu Preotiuc-Pietro [mailto:radup@bea.com]
Gesendet: Donnerstag,
10. April 2008 00:13
An: sdo@lists.oasis-open.org
Betreff: Re: [sdo] Re:
Comments on Blaises Proposal
See my comments inline:
On Wed,
2008-04-09 at 13:49 -0400, Blaise Doughan wrote:
>
> 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.
>
I definitely remember containment being
mentioned as one of the pain
points. But what I also remember is a couple of
use-cases being brought
up in support of that assertion:
1) the desire to
"SDO-ize" arbitrary/annotated POJOs so that SDO
metadata introspection and
SDO dynamic APIs can be used in an
application that formerly only dealt with
POJOs;
2) make it possible to also potentially generate change summary
for
POJOs "under the covers" thus opening up a new kind of clients for
the
DAS
Neither this nor Issue 66 is really addressing the above 2
points that
were raised at the F2F. I have made a proposal on this mailing
list a
while ago that does address them based on the idea that
containment
information is always present for the situations where it is
needed, but
in situation where it is in the way it can be ignored. I will
upload the
proposal to the OASIS site, to make it easier to reference
it.
> [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.
That's fair enough. While I am a little doubtful of
the usefulness of
deriving keys from XMLSchema key/keyref (because key/keyref
is difficult
and has a lot of subtleties which is also why it is not that
widely
used), I can see how can this could be useful. But:
- since the
relational mapping is not a proposal but an example, it
cannot be used to
support the need to introduce the concept; let's leave
it to the DAS to
decide what they want, and if they decide support for
keys is needed at the
SDO level, then of course that would be all the
support that would be
needed
- it's a very different thing saying that SDO will support
(composite)
keys for the sake of making the SDO metadata richer and more
attractive
to a class of use-cases than saying that composite keys are
required for
SDO to work at all. The elegant thing about the ways IDs are
used in the
current SDO is that they are used if present, but things work if
not
present. I am hoping that none of the SDO 3 algorithms would depend
on
the composite keys, but they could be adapted to use them if
present.
This is why I am thinking that these two are orthogonal. And
then the
medatadata mapping examples, I will take them as such, sorry for
the
misunderstanding.
Radu
>
> ----- 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
>
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]