[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [sdo] ISSUE 66: Moving Data Between Contexts: 1st proposal
Hi Ron,
This is a good discussion. Here are more thoughts.
1. I think that initially we should just say that properties that are not
available in a subsetting context are not visible. However, in the future
I could imagine relaxing this and saying that it is possible to have a
static property in one context appear as open content in a compatible
context.
2. I think you're right that the definition of compatibility can be
defined "in terms of all properties ever used". Specifically, I think we
can say that a DataObject has a "conceptual type definition" equal to the
definition in the context where it was created. Then, we can say that you
can project to a context that's a subset of the this DO conceptual type.
Later you can project to another context that is a superset of the current
context, but it can't be a superset of the DO conceptual type. This seems
simple enough to me, and we can still think about relaxing it a bit in the
future, for example, to take open content compatibility into account (like
comment #1 above).
3. Good point about not wanting to lose the ability to keep both the
Sequence and DataObject views in sync. I think the answer to this is that
we should describe two kinds of projections: 1) project to a different
interface in the same context, and 2) project to a different context.
I think the first kind, is really like a cast (it may sometimes actually
result in a Java cast in some implementations, but not always). In this
case, the original pointer is not suspended. Examples would include
casting to Sequence or to a static interface. My proposed project()
convenience method on DataObject (which by definition uses "the
HelperContext of this DataObject" would never suspend the original
reference. I think this intra vs. iter context projection is analogous to
the way SCA has local and remote wiring. This seems clean and elegant to
me - simpler than defining two different concepts/APIs for these two kinds
of projections - e.g., project() vs cast().
Thoughts?
Thanks,
Frank
"Barack, Ron" <ron.barack@sap.com>
03/17/2008 04:27 AM
To
Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org>
cc
Subject
AW: [sdo] ISSUE 66: Moving Data Between Contexts: 1st proposal
Hi Frank,
Very interesting ideas. I really wanted to get the properties to not have
to match up one-to-one, but I just wasn't sure how to describe it. As you
point out, everything has to round trip. In the case where you're
projecting to something that has more properties than you have, we start
getting into the problem what the values are of the "new" properties.
Can't just say "default" values here... It could be that it's the second
half of a round trip, and I think we agree that in that case the original
values should be used. You also start getting wierd situations when a
third context comes into the picture. You could have two contexts that
both compatible with a third context, but not compatible with each other.
And you get the problem of how the extra properties are represented in the
context that has fewer properties. Open Content? Invisible? Do they
show up in the sequence?
I would love to solve these problems. Having properties that don't match
up one-to-one would probably allow us to handle different versions of
types in different contexts, and that would be really important. I wanted
to avoid talking about "the underlying data structure", because we would
then have to describe it and the what compatibility means between a DO and
this underlying data structure. Maybe we could describe things in terms
of all properties ever used in a "project"...
Anyway, by thinking was only that we should leave this problem for later,
and get the basic project method described now, for this simple and easily
described case, with which we can still do useful things.
The reason why I didn't include an API for projecting to POJOs is only
because I wanted to address that in a seperate issue. I find your API
acceptable. It might be slightly more elegant to have a "POJO context",
where projecting to this context returns POJOs, but the functionality
would be the same.
Regarding "sequence". Personally, I always hated the idea of having
"getSequence" on DataObject, and, like you, I think of Sequence as being
very XML specific. On the other hand, I think the idea of allowing users
to set the sequence by calling type-safe setters on the static SDO, eg,
sequencedObject.setFirstName("Max");
sequencedObject.setLastName("Musterman");
sequencedObject.setFirstName("Henry");
sequencedObject.setLastName("Patterson");
is a cool usability feature that it would be sad to give up.
Ron
-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Freitag, 14. März 2008 21:15
An: sdo@lists.oasis-open.org
Betreff: Re: [sdo] ISSUE 66: Moving Data Between Contexts: 1st proposal
Hi Ron,
Thanks for writing this up. Here are some initial thoughts.
You say that an implementation may loosen the compatibility requirements,
for example, to allow T1's properties to be a subset of T2's. First of
all, I think this will be a very common scenario, so it should be
described as clearly compatible. Also, to allow roundtripping in this
case:
o1 = c1.getDataHelper().project(o2);
o2 = c2.getDataHelper().project(o1);
it would also need to allow T1's properties to be superset of T2's. I
don't think that's really a problem, assuming that the underlying
structure actually includes all the necessary data - which I think is the
real definition of compatibility. That is, the target type needs to be
compatible with the underlying data of the DataObject, not necessarily
it's current type.
You didn't actually show the intended signature of the project() method.
I'm assuing:
DataObject project(Object sourceObject);
I wonder if we should instead, or also, have a project() method that looks
like this:
<T> T project(Class<T> targetClass, Object sourceObject);
With it, one could also convert to a POJO view:
HelperContext myHelperContext = ...
DataObject myDO = ...
Customer cust =
myHelperContext.getDataHelper().project(Customer.class, myDO);
To go back to the DataObject view:
myDO = myHelperContext.getDataHelper().project(DataObject.class,
cust);
And, of course, we can go to another compatible context's view:
HelperContext context2 = ...
DataObject ccontext2DO =
context2.getDataHelper().project(DataObject.class, myDO);
I'm also wondering if it might be useful to add a convience project()
method on DataObject:
/**
* Projects the current object as an instanceof the specified class.
* Same as calling helperContext.getDataHelper().project(targetClass,
this),
* where helperContext is the HelperContext of this DataObject.
*/
<T> T project(Class<T> targetClass);
Maybe we could even use this as a replacement for getSequence(), since
Sequence is also just another view of the underlying data. For exmple:
Sequence sequence = myDO.project(Sequence.class);
Anyway, that's it for now.
Frank.
"Barack, Ron" <ron.barack@sap.com>
03/13/2008 11:01 AM
To
<sdo@lists.oasis-open.org>
cc
Subject
[sdo] ISSUE 66: Moving Data Between Contexts: 1st proposal
<<Dok1.doc>>
Hi,
Here is a first pass at a concrete proposal regarding the compatibility
and the project() method. Comments (and re-writes) very much welcome. The
section numbers are based on the current working draft:
http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26863/OASIS%20SDO%20For%20Java%20Spec.doc
Ron [attachment "Dok1.doc" deleted by Frank Budinsky/Toronto/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]