[Dev] The Chandler/Cosmo sharing format

Morgen Sagen morgen at osafoundation.org
Mon Mar 13 14:00:49 PST 2006


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.





More information about the Dev mailing list