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: AW: [sdo] ISSUE 66: Moving Data Between Contexts


Hi Guys,

I don't think that we want to introduce some kind of new API like 
HelperContext.setContainmentOn() or setContainmentOff(), but I think 
Radu's concept of containment on/off is a very useful way to think about 
context views and compatibility.

I think the right way to think about containmentOn/Off is as a 
"characteristic of the metadata" in a given context. For example, assume 
we have a simple context C1 with types A1 and B1. Assume that there is at 
least 1 containment reference between them. I would call this a 
"containmentOn" context. Now lets assume we have another context C2 with 
compatible (Ron's term for being castable) types, A2 and B2. Let's assume 
that in C2 there are no containment references at all. I would call C2 a 
"containmentOff" context. Now, we can think of "turning containment on" as 
simply casting from C2 to C1, while "turning containment off" can be done 
by casting from C1 to C2.

If you think of "containment on/off" this way, while reading Radu's 
thoughts (bullets 4-9) below, I think its providing some very useful input 
on how we might define compatible contexts, and when we could have 
multiple views on the same data. Bullets 6 and 7 are particularly 
interesting things to consider, IMO.

Frank




"Barack, Ron" <ron.barack@sap.com> 
02/27/2008 11:25 AM

To
"Radu Preotiuc-Pietro" <radup@bea.com>
cc
"Blaise Doughan" <blaise.doughan@oracle.com>, Frank 
Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org>
Subject
AW:  [sdo] ISSUE 66: Moving Data Between Contexts






Hi Radu,

Thanks for the interesting ideas.  Let me add my comments point by point.

1.  AFAIK, Java, also Java Serialization does not have any sort of 
containment relationships.  Unless you want to look at the heap, or the 
"ser" byte stream as being the container for all java objects.  Which is a 
valid viewpoint and more or less motivates the "technical root" (I used to 
call it "domain object") idea exposed by Xcalia.

2.  In this use case, where the data is coming from XML, and eventually 
will be serialized back into the same form, what is the motivation for 
"turning off" containment?  It seems like the main motivation here is to 
allow the user to put the objects, at least temporarily, in illegal states 
(e.g., where the object has 2 containers).  Of course, by the time the 
object is serialized back to XML, it must be in a legal state.  Your use 
case is that the data comes in as XML, and goes out as XML, too.  Very 
AquaLogic.  This is somewhat different from the usecase I'm thinking 
about.  I was thinking that the data is being delivered from some source 
(such as an RDB) in which the idea of containment is not natural.  In my 
use-case we are not turning containment off and on, we are adding it in. 
One of the main differences here is that, when adding containment 
information in, you can add it in in different flavors.   For instance, an 
RDB DAS that delivers SDOs for a School, with Students and Courses can be 
used to generate XML in which the Students "contain" Courses or one in 
which Courses "contain" Students, depending on which containment 
information is added in.

But back to your use-case.  I want to point out that it is extremely 
difficult to derive the value of "getContainer" if you are not maintaining 
it all along.  Having played with different ways of dealing with 
containment, I can definitely say that this method places a very big 
limitation on our options.  Remember, that the object may not (and objects 
defined by XML typically don't) have any property that points back to ist 
container.  From looking at an object, or even analysing the type system, 
you still can not definitely deduce the type of the containing object. 
Basically, I'm saying you can only turn containment on at the root of a 
tree.  (This is also true for the cast operation, BTW: O2.getContainer() 
will be null unless it was already casted into C2).

3. The only way to implement change summary in this scenario is as a 
"diff" between the before and after states.  We are loosing the option to 
implement change summary by tracking changes.

4. I'd like to explore the "containmentOn" operation a little deeper.  At 
which level do you imagine doing this?  At the context level, something 
like helperContext.setContainmentOn(true)?
Or on the dataObject?  If it's on the helperContext, I think you're asking 
for problems regarding the calculation of getContainer(), which I assume 
you're doing when setting containmentOn.  Depending on which root you 
start from, you could get very different graphs.  If on the other hand 
it's on DataObject, then effectively, you are "casting" the object into a 
identically defined (modulus containment) context, except that, I suspect, 
you're going to start getting into ugly situations as soon as you start 
mixing data objects with containment "on" with others with containment 
"off" in a single data graph.

Ron

-----Ursprüngliche Nachricht-----
Von: Radu Preotiuc-Pietro [mailto:radup@bea.com] 
Gesendet: Mittwoch, 27. Februar 2008 00:08
An: Barack, Ron
Cc: Blaise Doughan; Frank Budinsky; sdo@lists.oasis-open.org
Betreff: Re: AW: WG: [sdo] ISSUE 66: Moving Data Between Contexts

Hi all,

This is my thinking on the issue. It's merely putting together different
ideas that have been discussed on the calls and at the face-to-face in
an order that made most sense to me.

Let me start by reiterating some of the observations that I may or may
not have completely expressed on the call.

1. Containment is useful for any kind of serialization. The difference
between XML serialization and Java serialization is of course that Java
serialization infers its containment relationship at serialization time,
while in XML, it is predefined.
2. When creating POJOs from serialized form (let's say XML) and saving
them to XML, conceptually we can see the process as:
  a) create a graph of objects with a containment relationship given by
the containment relationship in the XML text
  b) turn the containment "off" before returning the object graph to the
user
  c) turn the containment back "on" after receiving the object graph
back from the user, according to XML metadata on hand; this process may
produce errors
  d) serialize the object graph with containment to XML
3. Containment is useful for ChangeSummary; mainly because it helps
establish the scope of change summary; SDO "knows" how to do
ChangeSummary with containment.

Those "observations" led me to believe that it would be useful to have
an ability to "turn containment off" on a graph of DataObjects. The
obvious purpose being to allow modifications to the DataObjects without
side-effects and without the need to worry about breaking the
containment restrictions in those applications which do not care about
them. Let me, for lack of better terms, call "containment off" the state
of a graph of DataObjects where the containment information in the SDO
metadata is "turned off" (ignored) and "containment on" the opposite
state. In SDO 2.1, all graphs of DataObjects are in "containment on"
state. Note that we would still need to define what a graph of
DataObjects is in the absence of containment, but let's leave that aside
for now.
More precisely:

1. In a "containment on" state, getContainer() works according to SDO
metadata (returns non-null except of course for the root). That means,
in a "containment on" state, containment is managed. Otherwise, we can
end up with two parents for a node and getContainer() breaks.
2. In a "containment off" state, getContainer() returns null.
Containment is not managed.
3. XML serialization works on graphs of DataObjects that are in
"containment on" state
3. Regarding ChangeSummary interaction, we define the Change Summary in
terms of diff between two "containement on" states of a graph of
DataObjects. That means, in order to get a ChangeSummary and start
logging, the graph of DataObjects must be in a "containment on" state.
In order for other ChangeSummary methods to return "defined" results,
the graph of DataObjects must also be in a "containment on" state. That
however, makes it possible to move to a "containment off" state right
after calling beginLogging(), make modifications, move back into a
"containment on" state and get a meaningful ChangeSummary. Users would
need to understand that moving into a "containment on" state when there
are changes being tracked is a potentially expensive operation and could
throw exceptions, but implementations would be free to innovate. All
that the spec requires is that conceptually, it behaves as a diff. This
way we would also make a step toward resolving the problem of defining
ChangeSummaries more precisely.


So then, in relation to the "Cast" proposal, we have:

4. When casting a non-SDO POJO to a DataObject graph, the resulting
graph of DataObjects would be in a "containment off" state. Because of
that, writes can be done without side-effects using either "view".
5. One DataObject would have a single "view" in one context.
6. If a certain "piece of data" (undefined term alert!) has multiple
"containment on" views, then the data is read-only in all "views". If
there is only one "containment on" "view", the data can be modifed only
"through" that view. If there are no "containment on" views (only POJO
views and DataObject "containment off" views), there are no
restrictions. This is so that we don't have to reconcile containment
with arbitrary modification of data by a POJO view: getContainer() would
be broken, ChangeSummary impossible to maintain in a incorrupted state,
what was a DataObject graph at the time of the projection would turn
into a collection of unrelated graphs after a few sets.
7. It should be easy to restrict bullet 6 further to not ever allowing
more than one "containment on" view at the same time; I don't see what
use-case would that prevent. We could also restrict "read-only" to mean
"inaccessible; no reads": even better but less clear that it would also
cover sufficient use-cases (I'd be happy if it does from the perspective
of it being easier to write a crisp spec)
8. If we allow modification to be made through a "containment on" view,
then potentially a POJO "view" would see side-effects, but that
shouldn't be a problem, it the sense that it is clear that if you have a
"view" to modifiable data, then, well, you'll see the data changing.
9. I am still considering whether something like a "copy-on-write" would
be desireable when sharing data using the "Cast" mechanism, but for that
I would say we do need use-cases.

That's it from me for now, hopefully it will turn out to be a worthwhile
(though long) read... :-)

Radu

On Tue, 2008-02-26 at 15:48 +0100, Barack, Ron wrote:
> Hi,
> 
> 1. What is the state of O1 after casting to O2?
> Imagine that O1 and O2 have diffent containment structures, or that O1
> has containment relationships, and O2 does not.  One reason for
> suggesting that O1 should be invalid is the side effects due to
> containment (that is, putting something in one container has the
> side-effect of removing it from the other container) will be
> inexplicable to users who are only aware of O2.  We will bring forward
> a proposal to replace the side-effects with exceptions... but the
> unexpectedness of the result remains the same.   If we invalidate O1
> after the cast, then we can ignore O1s containment constraints for as
> long as the user is working with O2.  When the user reactives O1 (by
> casting from O2), SDO can check if all of O1 containment constraints
> (e.g., that objects are not in 2 containers) are met, and throw an
> exception then.  This is at least a point in time when the exception
> would be expected.  Also, the illegal state may have been only
> temporary.
> 
> 
> 
> 
> ______________________________________________________________________
> Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] 
> Gesendet: Montag, 25. Februar 2008 22:20
> An: Barack, Ron; Frank Budinsky
> Cc: sdo@lists.oasis-open.org
> Betreff: 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()?
>       * O1.getChangeSummary().isLogging() ==
>         O2.getChangeSummary().isLogging() 
>       * O1.getChangeSummary().getOldSequence(aDataObject) ==
>         O2.getChangeSummary().getOldSequence(aDataObject)
>         Note identity might be too strong a requirement here, the
>         returned Sequence may only need to be equivalent. 
>       * O1.getChangeSummary().getOldValue(aContext1Property) ==
> O2.getChangeSummary().getOldValue(theCorrespondingContext2Property)
>         Note that although the dataType=true properties would be
>         identical, the dataType=false propertie values would be the
>         equivalent from the other HelperContext. 
>       * O1.getChangeSummary().getOldValues(aDataObject) ==
>         O2.getChangeSummary().getOldValues(aDataObject) 
>       * O1.getChangeSummary().isCreated(aContext1DataObject) ==
> O2.getChangeSummary().isCreated(theCorrespondingContext2DataObject) 
>       * O1.getChangeSummary().isModified(aContext1DataObject) ==
> O2.getChangeSummary().isModified(theCorrespondingContext2DataObject) 
>       * O1.getChangeSummary().isDeleted(aContext1DataObject) ==
> O2.getChangeSummary().isDeleted(theCorrespondingContext2DataObject) 
>       * O1.getChangeSummary().getDataGraph() !=
>         O2.getChangeSummary().getDataGraph() 
>       * O1.getChangeSummary().getRootObject() !=
>         O2.getChangeSummary().getRootObject() 
>       * O1.getChangeSummary().getOldContainer(aDataObject) !=
>         O2.getChangeSummary().getOldContainer(aDataObject) 
>       * O1.getChangeSummary().getOldContainmentProperty(aDataObject) !
>         = O2.getChangeSummary().getOldContainmentProperty(aDataObject)
> ---
> 
> 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 
> 

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]