If you’re running a website for a school, or a business, or a band, or a club, there’s probably a tab on your site’s home page labeled Events. The calendar that shows up on that page is most likely driven by some kind of content management system that collects your events using a form, stores them in a database, and renders them through an HTML template to produce your events page.
One of the premises of this series is that publishing calendars as HTML, for people to read on your events page, is necessary but not sufficient. You should also want to publish events as data for computers to process and for networks to syndicate. And you should expect your content management system, which already has the data in a machine-friendly format, to do that for you. But this almost never happens, and so we have a classic chicken-and-egg conundrum. Nobody expects that a website’s events page should offer a parallel data feed, so nobody demands that CMS vendors provide one, and as a result hardly any do.
Consider the case of the Hannah Grimes Center in Keene, NH. Its events page is provided by the Constant Contact service as part of a package of event marketing features that include registration and social media promotion. But there’s only an HTML page; no companion iCalendar feed is available. That means the Hannah Grimes Center’s events aren’t available as a stream of data that can syndicate through networks and merge with other calendars.
The irony here is that a previous version of the Hannah Grimes site did provide an iCalendar feed. In that version, the events page was served by Drupal. It has a calendar module that publishes event data two ways: as HTML, and as iCalendar. Last week I happened to meet the site’s coordinator; she wondered why their event stream had dropped out of syndication. I explained, and she wrote back the other day saying: “We’re in the process of converting back to Drupal for events!”
Drupal is a great system, and that’s fine, but it shouldn’t be necessary. Every CMS that produces an events page should also produce an iCalendar feed. When I talk to CMS vendors they confirm what I’ve said here: Customers don’t ask, so vendors don’t provide. What I also hear from them, though, is that producing an iCalendar feed seems like a lot of work. It isn’t. Libraries are available to simplify the translation from programming-language data structures to iCalendar feeds. And even without such libraries, it’s not hard to whip up a simple iCalendar feed.
My vision for a network of iCalendar feeds is inspired by the early blogosphere’s network of RSS feeds. Content management systems, like Radio UserLand, produced those feeds automatically. But many of us also produced our own feeds without the aid of kits. We did it “by hand” — that is, by interpolating variables into XML templates. It was easy to do, and it worked well enough to enable our homegrown feeds to participate in the emerging RSS ecosystem. In this week’s companion article (“How to translate an OData feed into an iCalendar feed“) I show how the elmcity service uses a library to produce iCalendar feeds. But if you look at the sample feed at the end of that article, you’ll see that — like the RSS 0.9 many of us created by hand — it isn’t really rocket science.
There was, of course, another reason why the homegrown approach worked as well as it did. It’s true that we didn’t have tools to help us write RSS feeds, but we did have a tool to validate them. The Feed Validator, originally created by Mark Pilgrim and Sam Ruby, was — and remains — a pillar supporting the RSS (and now, RSS/Atom) ecosystem.
When I set out to bootstrap an iCalendar network, I realized that there was no analogous service to validate iCalendar feeds. So I reached out to Doug Day. He’s the author of DDay.iCal, which is the open source library that the elmcity service uses to parse the iCalendar feeds it gathers into each hub, and also write iCalendar feeds that merge all of the inputs to each hub. Doug thought there should be a validator for iCalendar feeds, so he stepped up to the plate and created one at icalvalid.cloudapp.net.
If you’re a school or a business or a band or a club whose website sports an Events tab that doesn’t offer a companion iCalendar feed, I hope you’ll ask your CMS vendor why not. If you’re one of the vast majority of CMS vendors whose systems create events pages but don’t produce iCalendar feeds, I hope you won’t wait to be asked. With or without tool support, it’s not hard to make them. (See this week’s companion article for a C# example based on Doug Day’s DDay.iCal library.) And, thanks to Doug, there’s now a validation service to help you make them right.
Related: