iCal Redux 2003

Well, here we go again. 14 months after Apple got us all in a dizzy over their new iCal app for OSX, the subject has come up again thanks to a recent post by Ray Ozzie asking about what has been done to integrate calendaring and RSS.

During the last go around, I actually did some research to better educate myself about the various vCard, vCalendar, iCalendar, xCal spec names. What I found out was simply that iCalendar (normally called iCal) was the latest standard calendaring spec which is what Apple used for their iCal app and that it wasn't XML and that there was an XML version of the spec being drafted. Read my original post for more details and history.

Doing some research right now, it looks as if the xCal spec (iCalendar DTD Document) has been abandoned since the last public document expired in August 2002. This is too bad as an XML version would be nicer to parse than the way that iCal is written now with names deliminted by newlines and colons and dates in hard to consume formats.

While I was looking at this (up too late when I should be resting) Danny Ayers post on the subject filtered through my aggregator. It seems that some people at the W3C have been working on the calendaring/syndication problem using RDF and he points to Libby Miller's detailed post about it. Interesting.

Libby points out a draft for an event namespace that looks pretty clean, but it's not nearly as rich or as thought out as something like iCal, so it's not an option. The other item Libby points out is the working group that has been working RDF Calendaring, which from my cursory overview is basically iCalendar converted into RDF.

It's the right idea - any new calendaring XML spec out there has to be based off of iCalendar, especially now that Apple has gotten a zillion calendaring clients out there to support iCal, there's no reason to go off in a completely new direction for no reason. I also use MozCalendar which supports iCal as well (err. not "as well" but more like "also") and thus I can use great resources like Apple's iCal Library and iCal Share to find public calendars full of events.

However... RDF? Oh-oh. People who love RDF seem to love complexity, as Libby herself writes: "instead of some vanilla XML format like xCal..." AAAH! Vanilla is *good*. Urgh. But okay, I'm not trying to start another standards war with this one as long as it's CLEAN, and after I checked out some of the RDF-iCal Examples it actually doesn't seem that bad, so no I won't stress. I think it's too bad that xCal died since it would've been nice to have something vanilla, but if RDF-iCal is the only spec "living" still, then so be it, it looks fine to me.

The cool part about RSS + iCal (or RDF-iCal as the case may be) is that items and events line up so seamlessly. This spec will work in either RSS 1.0 or 2.0 (I assume) just by adding an additional namespace and entering <ical:event> tags into the item. Actually, there's something I don't know about namespaces: Is there anyway to "double up" on tags? For example, the <ical:summary> tag and the item's description tag are incredibly similar - it's too bad that couldn't be the same thing.

Honestly though, after all this thought, I wonder what this would give you. iCal is amuch richer spec when it comes to calendaring, events and todos than RSS... why throw out most of the spec just to include it in your aggregator? It seems like 1) Aggregators would be better off learning how to undestand .ics iCalendar files like Apple and Moz's calendars, right? or 2) Just shove the whole basic iCal doc into an item's description as it is now - we've already got escaped HTML in there, it's not like anything uglier than than that is possible. And that way when changes to the calendaring doc are discovered at all, your aggregator would redisplay it at the top...

Anyways, my thoughts on this subject a year or so later. See you again in 2004.


< Previous         Next >