[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WG: [sdo] ISSUE 66: Moving Data Between Contexts
Hi Everyone,
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.
____________________________________
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()?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]