meyerweb.com

Over at Complex Spiral Consulting, I maintain a list of upcoming appearances at conferences, workshops, and the like. These are the “public” events; that is, events which are accessible by members of the public, assuming they pay whatever registration fee is being charged by the people in charge of the event. This is in contrast to “private” events; that is, client work that isn’t open to anyone except employees of the client.

Occasionally I’m asked if I have an RSS feed of those events, or send out e-mail updates, or otherwise provide any sort of notice other than just changing the web page. For a long time, the answer was basically “no”. Now it’s “yes”, and it’s an example of a microformat in action.

If you’re using iCal on OS X, or any other webcal:-aware calendaring program, then all you have to do is hit the following link: Complex Spiral upcoming events calendar. Your calendar program should come to the foreground and let you add the URI as a subscribed calendar. And hey presto! You’re done. Any changes to the web page will be reflected in your calendar the next time the subscription is refreshed, and iCal lets you set your refresh interval to be 15 minutes, once a day, once a week, and so on.

What’s happening there is you’re pouring the home page of complexspiral.com through an XSLT recipe called X2V written by Brian Suda. His XSLT pulls out the hCalendar markup and turns it into an ICS file, one fully conformant with RFC 2445. So I don’t have to figure out how to produce and provide my own ICS file. Providing the hCalendar markup is enough, thanks to Brian’s work.

Of course, the number of people who would want to subscribe to my professional appearances schedule is fairly small. This is just a demonstration, though. Suppose a site like, oh, upcoming.org were to publish their event calendars with hCalendar markup? Then all you’d have to do is find the page that corresponds to your city, run it through Brian’s script, and you’d have your very own regularly updated local events calendar, just like that.

Guess what? You can do that right now: upcoming.org is publishing its information using hCalendar markup. For example, here’s the calendar for Cleveland, Ohio, ready for one-click subscription: Cleveland events calendar. If you just want the ICS file to be downloaded to your hard drive, then you can use this link instead: Cleveland events ICS file. The only difference between the two links is that the former uses the webcal: scheme identifier, whereas the second uses the more familiar http:.

I personally think there needs to be some work done on their hCalendar markup, like properly marking up location information. The time information for some events seems to be a bit wonky as well, although the dates are accurate. The great thing is that the hCalendar information could be fixed in very short order. In fact, from what I’ve heard, they added basic hCalendar markup to the site in under an hour. Adding more, or fixing any problems in what they have, shouldn’t take much longer.

Imagine how much further this could go. Suppose Basecamp marked up its project calendars with hCalendar, and used a script like Brian’s to turn it into ICS information. Its users could have project milestones right there in their personal calendar programs. Ditto for the To-Do’s lists, because that sort of information is all defined in the iCalendar specification. The TiVo site could provide customized schedules, like all the showings of American Idol or Masterpiece Theater. The IMDB could publish movie opening dates in hCalendar format; studios could do the same. Want a calendar schedule that shows what DVDs are coming out, when? Or what new albums are being released for the next month? All it takes is a little slice of a webmonkey’s time.

The point being, there’s nothing for which said webmonkey has to wait. The tools are already here. No browser has to be upgraded. In fact, in many ways this bypasses the browser to send information directly to the calendaring program… but the information is provided in a browser- and search-engine-friendly way, so they can access and use the same data in their own ways. No alternate files. Just a single set of information, made more rich and useful through easily understood mechanisms.

How cool is that?