[Dev] The Chandler/Cosmo sharing format

[Lisa Dusseault]

This gets Chandler to be interoperable with other calendar clients, but  
only if Cosmo is used.  It doesn't get Chandler to be interoperable with  
Hula, Oracle server or other CalDAV servers, or is that still going to  
work as it does today?

Perhaps we have different assumptions about the interoperability  
requirements, there's been some talk about making that more explicit.

lisa

On Mon, 13 Mar 2006 14:00:49 -0800, Morgen Sagen  
<morgen at osafoundation.org> wrote:

> I haven't responded to this thread in a few days since other things have  
> been coming up, but I wanted to fill people in on my current thinking.
>
> First a recap of the sharing format goals:
>
> 1) Decouple format from Chandler internal domain model
> 2) The format should be extensible to support new data types
> 3) Strive to use existing standards
> 4) Support stamping (an item can be of multiple types simultaneously)
> 5) Single resource per item
>
>
> Proposal:
>
> When Chandler shares a collection, a single Cosmo collection is created  
> (i.e., one-to-one mapping between collections), and for each item in the  
> Chandler collection, Chandler publishes an RDF/XML resource into that  
> Cosmo collection.  Cosmo scans each resource for any calendar-specific  
> attributes (identifiable by XML namespace) and stores those as  
> properties on the resource in order to perform any CalDAV-specific  
> actions it needs to do, like serving iCalendar to CalDAV clients.  When  
> a CalDAV client publishes an iCalendar resource, Cosmo parses the  
> iCalendar and modifies the RDF/XML resource accordingly.
>
> Chandler still gets to share any type of data, Cosmo only needs to  
> understand a subset of that data, there is one DAV resource per item,  
> and we get interoperability with other clients.
>
>
> Rationale:
>
> All the goals can be solved by having Chandler publish RDF/XML resources  
> which use 'well known' vocabularies, and we can add vocabularies for  
> data types that don't have a standard.  There is a spec for RDF/XML  
> syntax:
>
>     http://www.w3.org/TR/rdf-syntax-grammar/
>
> There are already RDF/XML vocabularies for various data types, so we  
> don't have to reinvent the wheel or develop specs for them:
>
>     Calendar:    http://www.w3.org/TR/rdfcal/
>     Contacts:    http://www.w3.org/TR/vcard-rdf
>     Mail:    http://www.openhealth.org/xmtp/
>
>  From responses on the dev list and from talking to people, I think most  
> of us agree that having multiple files representing an atomic entity is  
> undesirable.  I can tell you from experience that tracking multiple  
> resource bodies, URLs, and ETAGs for a single item is -- while possible  
> of course -- complicated and a bit inelegant for my taste.  I certainly  
> wouldn't expect the developer of some other client who wants to interop  
> with us to go through what Chandler currently does.  I don't want to  
> explain to this developer, "For these attributes read this resource body  
> in this format, and for other attributes read this other resource body  
> in another format.  Oh, and make sure you remember to process the XML  
> resources before the ICS resources."  And what happens when it's time to  
> implement CardDAV, add a third resource to the mix?
>
>
> Further details:
>
> There are some details to work out, including how clients and Cosmo  
> negotiate the content types being transferred.  At first it seemed like  
> using the Accept: header would suffice, but Brian Mosely recently found  
> some arguments for why relying on that header can cause confusion.   
> Perhaps we use different URIs for each content type; if a vanilla CalDAV  
> client puts a resource named 'xyzzy.ics', then Cosmo makes that item  
> available to Chandler as 'xyzzy.xml'.  Or perhaps we use a query string  
> to explicitly give type information.
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev