CalDAV. Yesterday's item drew comment from the Chandler team. In email (quoted with permission) Jeffrey Harris wrote:

Are you familiar with CalDAV?
At OSAF we're very interested in getting a workable standard going for
iCalendar over WebDAV, Lisa Dusseault has put time and energy into
creating a draft standard.

I've been working on a Python vCard/vCalendar parser
( as a prelude to writing the iCalendar
import/export code for Chandler. For the moment, we're just going to do
the dumb publish-a-monolithic-calendar thing so we can do the baby
steps of getting Chandler's calendar client interoperating. But in the
long term, we want CalDAV!

Lisa Dusseault, who is also an OSAFer and who has written a book on WebDAV, explains the motivation for CalDAV in a blog entry which says, in part:

interoperability has languished except for that burst of productivity
back in 1998. People are locked into one calendar application depending
on what server technology they have available, since there's no common
calendar access standard. [Not Invented Here]

Amen. It's a train wreck, in fact. 

The CalDAV proposal explains how WebDAV, being an extension of HTTP,
does all sorts of things you'd want a calendar server to do, including:

  • Expose data to a wide range of clients as HTTP URLs
  • Leverage TLS/SSL
  • Downshift for clients not needing advanced features (such as locking), upshift for those that can exploit such features
  • Be extensible, allowing new properties and also new methods

The bulk of the spec describes how to model calendar data as sets of
WebDAV resources and properties. It seems reasonable, though since I'm
no expert on WebDAV I'd benefit from an illustration of how everything
lays out with respect to the filesystem, which aspects use
backward-compatible iCalender syntax and which use XML, and what (if
anything) might change in the offline client-side file format.

A third OSAFer, Ted Leung, notes
that my wish to apply standard XML search technology to calendar data
could be granted by making XQuery (or presumably just XPath) one of the
grammars supported by WebDAV's search architecture, DASL (DAV Searching and Locating).

There does seem to be an opportunity here to kill two birds with one
stone. First, break calendaring out of its icejam. Second, tap into
WebDAV's mostly-unexploited power. In the scenario I described
yesterday, WebDAV is used as little more than an HTTPS-friendly version
of FTP. And so far as I can tell, that's typically how it gets used.
But WebDAV is far more capable, in ways that address basic challenges
that continue to bedevil our collaborative software.

Update: Scott McMullan's latest post adds several fascinating dimensions to this discussion. First, the work of Allison Bloodworth et al. on a calendaring project at Berkeley, based on document engineering. Second, the XHTML-based hCalendar idea which Scott found by way of Adam Rifkin's excellent riff on microformats.

Although my focus in this post and the previous one was mainly on
WebDAV, I'm glad to weave in these threads too. In fact, the approaches
Scott mentions resonate very strongly with the document- and
microformat-oriented ideas I discussed in one of my O'Reilly Network
columns, Interactive Microcontent.
Not co-incidentally, that column includes an XHTML representation of
some calendar events, along with JavaScript code (try it!) that picks
events out of the page and — the reader is invited to imagine — could
then transfer the resulting XML fragments into some other context.

Calendar events are just one example of a whole bunch of microformats
that we need to render and also interact with. Rendering is
straightforward, but to support interaction we need a data store that's
part filesystem, part database. (Or, in the long run, that is an object/relational/XML trinity.)
What hadn't occurred to me, until recently, is that WebDAV might be a
stepping stone along the way, marrying filesystem-like convenience with
database-like querying and locking. 
[Jon's Radio]

Leave a comment