AW: [sdo] ISSUE 66: Moving Data Between Contexts: 1st proposal

["Barack, Ron" <ron.barack@sap.com>]

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