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:
Calendaring 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:

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.

Former URL: