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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

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


Subject: Re: WG: [sdo] ISSUE 66: Moving Data Between Contexts


Hello All,
 
In my opinion the following answers are most consistent with the Java cast concept, or moving entities between JPA contexts.  This isn't an endorsement yet, just my current thinking.
 
1. What is the state of O1 after casting to O2?
a)  We require both O1 and O2 to be live views of the same underlying data.

2.  Does cast create objects, even if there are the underlying data already has a DataObject in the context?
Is C1.cast(C2.cast(O1)) == O1?  Yes
 
3.  How is the value of O2.getChangeSummary() related to the value of O1.getChangeSummary()?
---
 
For the following:
 
1. What is the state of O1 after casting to O2?
c)  We say that the state of O1 is undefined.  In order to "reactivate"  O1, we would have to cast it back from O2, that is we would have to
explicitly say O1=C1.cast(O2), which would make O2 invalid, but bring O1 back into a valid and consistant state.
 
I agree with Frank that simply changing the DataObject's Type is another way to move a DataObject from one HelperContext to another.  I wouldn't categorize this as a cast though, and if this became our agreed upon approach I would suggest a different API such as "move" or "adopt" (from DOM APIs).  Also instead of stating that the state of O1 being undefined, I would state that C2.cast(O1) would cause the following operation to happen (O1.detach). 
 
---
 
Role of the Cast Operation (Motivation)
 
Moving Between Helper Contexts
A cast/move operation appears necessary to move DataObjects from one HelperContext to another. 
 
Applying Containment Information "on-the-fly"
A cast/move operation as a mechanism to apply containment information for the purposes of mapping a DataObject to XML is too cumbersome as it requires many changes on the DataObject before the XML marshalling/unmarshalling operation can take place.  Compare this with a object-to-XML mapping tool such as MOXy which is part of EclipseLink (Eclipse Persistence Services) project which can apply many XML mappings to an object without any modifications to that object.
 
---
 
DataObject cast(Object object)
 
In my opinion:
The ability to cast Objects other than DataObjects is a possible next step, but I feel should be discussed in detail on its own before changing the proposed cast API.
 
 
-Blaise
 
----- Original Message -----
From: "Frank Budinsky" <frankb@ca.ibm.com>
To: "Barack, Ron" <ron.barack@sap.com>
Cc: <sdo@lists.oasis-open.org>
Sent: Monday, February 25, 2008 1:50 PM
Subject: Re: WG: [sdo] ISSUE 66: Moving Data Between Contexts

Hi Ron,

Thanks for kicking off this discussion. I agree it's a very important
issue.

For question #1, I think the answer needs to be c) O1 becomes
invalid/undefined. I think this is necessary to allow for the possibility
of O2 being the same instance as O1. I think the most efficient
implementation of cast() would return the same object if possible, just
with the type changed. For example, the HelperContext.cast() method might
do something like the following:

DataObject cast(DataObject input)
{
    Type inputType = input.getType();
    Type resultType = getTypeHelper().getType(inputType.getURI(),
inputType.getName());

    // check if types are compatible
    ...

    // Unrelated question: do we need to recursively call cast() on the
rest of the reachable objects ???
    ...

    // change the type
    ((DataObjectImpl)input).setType(resultType);

    return input;
}

This may not be always possible, but if the spec doesn't say that the
original object becomes suspended, there is no way we could ever implement
cast this way - it would always require at least a wrapper DataObject.

For question #2, I think that C1.cast(C2.cast(O1) should == O1. It
certainly would be the case if cast() is implemented as above. If, on the
other hand, a proxy is returned, I still think their can only be one
DataObject instance representing the same object in a given context.
Otherwise, we're talking about a copy - not a cast.

Which brings me to a question. Do we really think that cast() should ever
return a disconnected copy. In Java, cast and copy are very different -
one changes the type, the other changes the instance. I think that for
copy cross-scope copy we should allow/use cross scope CopyHelper. For
example:

O2 = C2.getCopyHelper().copy(O1);

This would create a copy of O1 in the context C2 (the same compatibilty
requirement as cast() would need to apply).

O2 = C2.cast(O1):

This returns the same conceptual object, just represented in the new
metadata (type) scope.

This way, cross-scope cast and copy are two different things with clear
APIs for both.

One more thought I had about cast() is that the argument to the cast
method should maybe be Object - instead of DataObject. That way, you could
use it to cast a POJO (or JAXB) object to a DataObject:

DataObject cast(Object object)

Now, if the input object is not already an instance of DataObject then the
default mapping rules (maybe there are also annotations) are used to check
compatibility, etc., before returning a DataObject proxy, for example.

That's all for now.

Frank.





"Barack, Ron" <
ron.barack@sap.com>
02/21/2008 05:20 AM

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

Subject
WG: [sdo] ISSUE 66: Moving Data Between Contexts






Hi Everyone,
 
OK, here we go... defining the cast method.  I think the concept is
actually simple, but it was hard for me to write down without having to
resort to this quasi-mathematical language.  Sorry about that.  Maybe,
once the concepts are clearer, someone else can do a better job.  Anyway,
we decided at the F2F that is was a high priority issue, and to get
started on it right away.  Please spend a few cycles on this topic, so we
can begin discussing it.
 
 
I've been trying, but I don't think it's possible to describe this
functionality without some definition of what it means for types to be
compliant.  So let me start out with the following definition, which I
believe to be too restrictive, but which at least allows us to speak
concretely about proposals.  The concept can always be loosened up in a
separate step.
 
Definition:  Compliance
 
A data type DT1 is compliant with a data type DT2 if they have the same
instance class
A complex type T1 is compliant with a type T2.  The types are compliant
iff
 
1.  The URI and name of both types are equal.
2.  For every property P1 in T1 there is a property P2 in T2 such that
     a) P1.getName() is equal to P2.getName()
     b) P1.getType() is compliant with P2.getType()
     c) P1.isMany() is identical to P2.isMany()
     d) if P1.opposite() is non-null, the P2.opposite is also non-null.
 
Of course, the key point is what is not looked at in determining
compliance.  This includes
 
1.  The instance class (static SDO of the complex type)
2.  Whether the value of P1.isContainment() is identical to the value of
P2.getContainment()
3.  The XML or Java names of the properties.
 
I believe we will someday be able to loosen this definition, for instance,
that the URI-Name pair does not have to match, or we can allow the
properties in T1 to be a subset of those in T2.  But we can already do
some pretty useful things with the definition.
____________________________________
 
Definition: CAST
 
Using this definition of compliance, I would like to define the following
operation in the HelperContext interface
 
     DataObject cast(DataObject)
 
with the following characteristics
 
1.  If there is no type in the current HelperContext that is compliant
with the type of the argument, an exception is thrown.
2.  If there is such a compliant type, the object returned will have this
type.
3.  The values of data type properties in the returned object have the
same value as the corresponding properties of the original data object.
4.  The value of complex typed properties in the returned data object are
data objects whose types are compliant with the type of the data object
returned by retrieving the corresponding property on the original data
object.
 
This is maybe clearer using the following semi-mathematical formulation.
 
Consider object O1, where O1.getType() is T1 and where
T1.getHelperContext() is C1.
Consider a context C2, having a type T2 that is compliant to T1.
Now
     DataObject O2 = C2.cast(O1)
 
For each property P1 in T1 there is a property P2 in T2 such that
P1.getName().equals(P2.getName() )
If P1.getType().isDataType() is true then O1.get(P1)==O2.get(P2)
If P1.getType().isDataType() is false, then if O1.get(P1) is null,
O2.get(P2) is null, otherwise
    O2.get(P2)==C2.cast(O1.get(P1))
 
__________________________________________________________________________
 
Now for some details I'd like to discuss:
 
1. What is the state of O1 after casting to O2?
 
In our implementation, and also in the description of the cast operation
that I gave at the F2F, each data object (O1 and O2) was depicted as a
"view" of the same underlying data.   The actual motivation for this
implementation was performance, that is, we wanted to avoid a copy step.
This has the effect that both O1 and O2 are "live", that is, changes to O2
are immediately visible in the O1.  This *could be* useful, but I would
also say that the vast majority of time, either O1 or O2 is active, not
both.
 
I see three possibilities for what we say in the spec:
a)  We require both O1 and O2 to be live views of the same underlying
data.
b)  We say that O1 is unchanged by operations on O2.  This more or less
requires a copy step, which would make the cast operation expensive.
c)  We say that the state of O1 is undefined.  In order to "reactivate"
O1, we would have to cast it back from O2, that is we would have to
explicitly say
     O1=C1.cast(O2), which would make O2 invalid, but bring O1 back into a
valid and consistant state.
 
2.  Does cast create objects, even if there are the underlying data
already has a DataObject in the context?
 
Is C1.cast(C2.cast(O1)) == O1?  Or, more fundamentally, does a data object
have only one ?view? in a particular context.   Imagine that the object
that is casted is the root of a complex graph, and that there are multiple
paths (i.e., through non-containment references) to some node in the
graph:  do we get the same object, no matter which path we take?  I would
say that all three of these behaviors are important.  To achieve them, the
mental model is that the underlying data representation ?knows? which data
object represents in which context.
 
3.  How is the value of O2.getChangeSummary() related to the value of
O1.getChangeSummary()?
 
 
Ron
 
Von: Barack, Ron [mailto:ron.barack@sap.com]
Gesendet: Montag, 18. Februar 2008 11:27
An:
sdo@lists.oasis-open.org
Betreff: [LIKELY JUNK][sdo] ISSUE 66: Moving Data Between Contexts

http://www.osoa.org/jira/browse/SDO-66

Von: Barack, Ron [mailto:ron.barack@sap.com]
Gesendet: Mittwoch, 13. Februar 2008 14:47
An:
sdo@lists.oasis-open.org
Betreff: [LIKELY JUNK][sdo] New Issue: Moving Data Between Contexts

Motivation:
HelperContexts were motivated principally by the need to allow JEE
applications to maintain independent type registries, protected from
possibly conflicting types that may be defined in other applications.  In
an SCA environment, we can imagine HelperContexts being associated with
contributions, since these normally define the boundries of artifact
resolution, which includes the XSDs, java classes, or whatever else is
being used to define types.
If we envision SDO being used as data transport in a SOA, for example, in
SCA wiring, then it becomes clear that SDO must also provide some
mechanism for moving data between contexts.  This is, in my mind, the most
common use-case for moving data between contexts.  On the other hand, it
is completely possible for a single application to want to manage multiple
contexts, and to want to move data between contexts.  In the discussion
that follows, moving data between applications should be considered as a
common use-case for a functionality that can also be used within a single
application.
More specifically along the lines of our charter, the ability to move data
between contexts is the central concept behind our approach towards
relaxing containment requirements.  We are envisioning that some
applications within the SOA environment will not have need for or interest
in signifying some relationships as being containment, while other
relationships are references.  Other applications will require
containment, perhaps because they will serialize to XML, perhaps because
they use some other feature, such as ChangeSummary, CopyHelper, or
EqualityHelper that relies on containment.  If we are going to relax
containment requirements, then we must either redefine these features
(which would break backwards compatibility), or we must find a way to add
containment information on the fly, so that this operations will still be
available for data objects that come from contexts where containment does
not make sense.  This operation, adding containment information
"on-the-fly", is, in this proposal, implemented as moving data objects
from a context where the types are defined without containment information
to a context where the types do have containment information.  As
previously stated, this could mean moving the data objects between
applications, or between contexts in a single application.
The cast() method, which I want to introduce with this issue, was
discussed at the F2F, and identified as a high priority for SDO 3.0.  For
more information on where this is all headed (slowly, with baby steps)
please see:
http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26723/Containment%20in%20SDO%203.ppt
and
http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26711/SDO3%20Java%20Projections.ppt

Description:
Consider a DataObject O1, with Type T1, defined in context C1.  Define an
operation that will "cast" from O1 to a DataObject O2, with Type T2,
defined in context C2.  The data objects O1 and O2 would provide
alternative views of the same data.  The Types T1 and T2 may differ
slightly, for instance, in how containment is defined.  In order for
casting to make sense, it will be necessary to define some concept of
"compatibility" of types, that is, what must T1 and T2 have in common, in
order for the cast operation to make sense.  I would, however, like to
leave the exact definition of compatibility for a later issue, and discuss
the operation in principle first.  The details of the relationship between
O1 an O2, for instance, if changes to O2 are visible in O1, however,
should be determined as part of the resolution of this issue.
Proposed Assignment JIRA Components:
Topic 10:  Containment
Topic 7: TypeSystem and Helpers



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