Sharing and attributes (Was: Re: [Dev] isPrivate: never-share flag)

[Lisa Dusseault]

Note also that to make different Chandler release versions interoperate 
with each other over the same shares, we'll have the same issues.  How 
will the schema on the WebDAV server be different from Chandler 1.0's 
internal schema? (Probably not much, except for CalDAV). How will the 
schema on the WebDAV server be different from Chandler 2.0's internal 
schema?  Probably more so.

One wild idea I had (and discussed a bit with Stuart) was to define 
transformations between formats.  If there was some standard way to 
spit out an item's attributes to an XML document in memory, then is 
there a straightforward transformation to turn that into a PROPPATCH?  
Vice versa, how about taking a PROPFIND answer (or fragment for one 
item) and turn it into a set of attribute values?  These 
transformations could be written as XSLT (or something else) and could 
be stored as data.  So then the way to share a given Item is to take 
the appropriate transformation based on that item's schema version, and 
apply it.

It's probably not really feasible for the sharing code to just ignore 
the attributes, no matter how we did sharing.  If I create a "knitting 
project" custom item for my "knitting management" parcel, then any 
schema changes risk breaking sharing of that data.  So the parcel 
developer has to keep in mind the sharing schema and at times make an 
adjustment.  In the first version my "gauge" attribute might be an 
integer (in stitches per inch.) In my next version I decide I need two 
attributes, one for  "stitch-gauge" and one for "row-gauge".  So as a 
developer of a parcel, I just have to write the code to take the new 
schema and make it spit out the old "gauge" attribute for backward 
compatibility with earlier versions of my own parcel -- likewise the 
new version of my parcel must understand when it sees a "gauge" 
attribute on a shared knitting project Item.  This logic is completely 
independent of protocol or whether the sharing data model is different 
from the internal data model.

Of course, one choice the parcel developer can make is to say that 
backward-compatibility in the face of schema changes is not needed.  
That's the only way I can see for parcel developers to be able to make 
schema changes and not write code.

Actually, I'm not too worried about the property/attribute connections. 
  What I'm more worried about is when the item boundaries change.  What 
if I decided Gauge was a complex reusable item and needed to be broken 
out as a completely separate item?  So that in one version of my 
parcel, each knitting-project item has an integer gauge attribute, and 
in the next version it has a reference to a Gauge item?

Lisa

On Nov 15, 2004, at 2:01 PM, Morgen Sagen wrote:

> On the other hand, sharing items with non-Chandler clients is a high 
> priority, and do we think that the schema these non-Chandler clients 
> use will exactly mirror the Chandler content model?  For example, 
> Chandler might internally model a calendar event differently from 
> CalDAV, and therefore the sharing layer would not "blindly" be 
> transferring event items to and from the server; rather, this layer 
> would need to perform transformations on the items, converting between 
> Chandler-schema and non-Chandler-schema.  So the question becomes, 
> what should the schema on the WebDAV server look like, and how does it 
> differ from Chandler's schema?
>
> On Nov 15, 2004, at 1:24 PM, Mike wrote:
>
>> +1
>>
>> John Anderson wrote:
>>
>>> I've been hoping that maybe we could handle the name issue in the 
>>> view, so that it would be possible for the sharing transport layer 
>>> not to know anything about the data that's being shared -- keeping 
>>> all attributes and the UUID of the items the same on all the 
>>> machines that have a copy of the item.
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev