iCal explorations

A couple of people wrote to point out that I'd given the impression that iCal was an Apple-only thing. Not so, of course. iCal is a standard with many implementations. One that I hadn't tried until yesterday is Mozilla Calendar -- it's available as an XPI-style extension and works, for me, with Windows and Mac versions of Firebird. (I had to also use the QuickTools extension in order to get Calendar to show up on the menu.)

As an experiment, I decided to see what it would take to get Outlook, which is currently my canonical PIM, to publish events to a public iCal file. I started with dump_props.py, which is a tool included with Mark Hammond's SpamBayes Outlook plug-in. This script, which showed me how to extract mail for fulltext indexing, is a great starting point for the novice Python/MAPI coder.

The script I came up with is crufty and doesn't do import yet, just export, but it works. As a result, I'm now even more aware of what I suspected about xCal, the (apparently now expired) proposal to XMLize iCal. xCal proposed a straight mapping of iCal elements to XML equivalents. Fair enough, and certainly helpful to applications that are parsing this stuff, but what struck me when I saw my events showing up in iCal, and when I looked around at other iCal data, is how impoverished the stuff is.

Back in 1977, at the dawn of the Java servlet era, I wrote a servlet-based group calendar. One of the delightful things about it -- to me, anyway -- was that calendar entries accepted HTML, so could contain links and rich formatting. Now we have the technology to treat such entries as structured data. But there's no place in iCal to put that stuff. XML calendar metadata would be useful, but not revolutionary. XML payloads, though, could really open some doors.

As Bob DuCharme said to me yesterday:

When I give an XSLT class, I like to point out that one key to its success is that you can create whatever XML serves your purpose and translate between your XML and that of your business partners as needed without waiting and waiting for a common format to share.
Exactly. There are a handful of things that absolutely must be nailed down to make something like iCal work. And then there are a million "nice-to-haves" that will never make it through the standards bottleneck. With XML Web services, we've concluded that all payloads are extensible. That seems like a sound principle to me, and fertile ground for innovation in other areas too. "But then, calendaring might as well just be an XML Web service." OK.

Former URL: http://weblog.infoworld.com/udell/2003/09/23.html#a802