Integrating RSS And Calendar

Summary:

This essay reviews several efforts made to represent calendar information, ways to publish and subscribe event listing and efforts that have been made towards extending RSS for this purpose. It points out difficulties in implementing the standards and proposes a solution. Date: May 23, 2005 Last Updated: June 2, 2005 Author: Shital Shah

The Idea

Almost every website owned by an organization or a group has some kind of event listing. Wouldn’t it be cool if those websites could publish these event listing through some kind of feed which users can consume and aggregate right in to their calendars? In this essay, we’ll discuss just that. There are several scenarios where this technology could be a blessing. For instance, you may be able to subscribe to your friend’s schedules and also to your office meetings. You can subscribe to ticket-master concerts dates or university symposiums or hike schedule from your local outdoor club or keep track of IMAX movies at your favorite theater. The essence of the idea is to unify all types of event listings in to a common machine readable and subscribable format so that your calendar program can keep itself updated automatically. Because of its popularity, RSS would obviously come to ones mind when one think about publishing and aggregating something. However we’ll see that the RSS is neither the only vehicle nor an ideal one for calendar feeds.

The Calendar Standards

Let’s start with the basics: Are there any standards at all for exchanging calendar information? According to some history, oldest one and still widely used is called vCalendar which is simply a plain text property-set type format. This specification was refined by IETF in the ‘90s and renamed as iCalendar (iCal for short). They kept the same text format as vCalendar because back then XML specs weren’t up yet and people hadn’t started craving for everything wrapped in angle brackets. Over the years iCalendar has became really popular even though it was pretty complex to fully implement it. Today, most calendar programs support iCalendar format at some extent and you can often find the data stored in this format in files with ics extension. However the biggest surge of iCal usage arrived when Apple decided to support it in its OS X. Apple’s iCal app allowed users not only to exchange their calendars but also subscribe to it! This essentially meant that the app would poll for updates to the iCal files hosted on the webservers at regular interval and automatically keep the user’s calendar updated. In my view this is one of the coolest things they have done in recent years and no wonder websites like sprung up overnight and made available thousands of calendars for free for all kind of event listings you could imagine: from Roman Holidays to Beach Nudist events to outdoor performances in Central Park. Apple users can subscribe to these schedules with a single click in their calendars. Even though websites such as Upcoming and Evdb supports iCal more than any other format, the “calendar subscription” revolution has remained more or less contained in tiny Mac users world. Outside of that world, most people don’t even know that you can do that kind of stuff. Microsoft didn’t seemed very interested (or shell we say, horrendously slow ) to include this community style feature in Outlook. Infect Outlook did such a bad job with iCal files that it’s a shame for such massively touted Office suite. For instance, you can’t even import perfectly valid standard iCal file if it had more than one event. However you can download Mozilla Calendar extension for Firefox or a standalone version of it called Sunbird and start using iCal files but both of these are at really primitive state right now.

Did You Said It’s Not XML?

After the XML specs got released in 1998, there begun a race to pack everything inside the angle brackets and poor old iCal wasn’t an exception. First effort to produce XML version of iCal standards was xCal. The xCal was plain vanilla XML tags conversion of iCal, i.e. it just used simple tags without namespaces. Later it was decided that it should rather be RDF instead the plain vanilla XML. The RDF essentially allows you to describe various properties of an entity and its relationship with other entities; much the same way you describe the entities using columns in data tables and use primary and foreign keys to relate other data tables. So the RDF killed plain vanilla xCal work prematurely and a W3C group started working on the one-to-one conversion of iCal to RDF, now referred to as RDFiCal . So who is using RDFiCal? Apparently few programs like Mozilla Calendar supports this format and there are program libraries available to work with it too but there is very little content available to consume. For example, iCalShare, the largest public calendar website, doesn’t care about publishing in RDFiCal format. While RDFiCal is still striving to get acceptance, a working group sponsored by International Press Telecommunications Council has announced that they have started working on something called EventML to describe events in XML format. While they are mainly aiming at events related to news and journalism industry (such as press conferences), there’s little doubt why it can’t be used for any kind of events in general. While the specs are still being worked on, it is quite possible that they pick up on popularity wave due to the support provided by major news media companies such as WSJ, AP and AFP. There is one more effort towards moving calendar info in to XML which is gaining fair attention. It’s called hCalendar and is simply a one-to-one representation of iCalendar data in XHTML. This brings home one significant advantage over RDFiCal: You can easily embed event information right in to your web pages (or your blog entry) using much more simpler XHTML syntax and use CSS to transform it in human readable form. The spiders landing on your web pages can parse the hCalendar information and use it in more meaningful way. If anyone rather wants it in older iCal format, you can use online scripts such as X2V for on-the-fly conversion. There are series of other XHTML based standards now collectively referred to as microformats . They enable you to do stuff like create an calendar entry in hCalendar format with a link to host’s contact information expressed as hCard and include reviews for that event as hReview - everything embedded in your XHTML page and rendered using CSS. Cool, right? It might appear that these microformats are trieng to compete with RDF in describing the same information in a simpler way however RDF wins hands down for it’s more richer, consistant, capable and extensible. Also the disadvantage with these microformats is that they are new and hence less popular. For example, Mozilla Calendar does not support importing or exporting as hCal yet. And however simple it might be, a very tiny percentage of people can actually write XHTML directly in their blogs or webpages unless hundreds of tools out there decides to upgrade themselves.

So, Can We Ride On RSS?

Having RDFiCal is good. Now you can think about wrapping it in RSS 1.0 or 2.0. For the recap, the RSS 1.0 is the RDF based syndication format while 2.0 is plain vanilla XML. No, RSS 2.0 is not a major upgrade on 1.0. They were done by different people almost in similar timeframe and unfortunately got stuck with the same name “RSS”. I don’t know what they were thinking but Dave Winer who updated his specs little later decided to bump up the version number high enough so that everyone thinks that his stuff is a huge upgrade over whatever other group did. Actually RSS 2.0 indeed has extra built-in 16 tags which means it can describe the feed and items in more details out of the box. Anyway, both are pretty extensible to include whatever extra info you would care. For instance, according to RSS 2.0 spec you simply need to put new elements in your own namespace to extend RSS . It’s so easy that it shouldn’t come as surprise that the spec for RSS 2.0 event extension is already out there. It’s called Event Share Specification, or ESS in short (which coincidently rhymes with RSS). The idea was that the websites would start putting up blue icons for ESS instead of orange RSS icon which people could use to subscribe to event feeds but this never quite got picked up. For RSS 1.0 extensions comes more “natural” and can inter-relate. For example, you can embed RDFiCal along with FOAF (Friend of A friend) and geo info in RSS 1.0 feed and do the RDF queries like: show me what my friends are up to this weekend in 20 miles of radius of my home. It turns out that RSS 1.0 also have an official extension module called RDF-Events. But unfortunately it was really basic and many people found that their needs aren’t being met. Both ESS as well as RDF-Events didn’t received much acceptance anywhere but we would see the reasons in a little while. One more way to include calendaring information in RSS feed is to use the enclosure which essentially allows you to attach a file along with your blog entry. This is the scheme used by sites like RSS Calendar. Just like podcasting where you include link to mp3 files in RSS item, you can include links to iCal files with MIME type text/calendar. To fully use of this scheme, however, an upgrade is required for the RSS readers so they can process these enclosures. Technically speaking, RSS in this scheme is essentially redundant because calendar programs can anyway keep polling webserver for updates to the iCal files; they don’t need RSS feed for that. The RSS feed only serves purpose to entice people who are exclusively Windows and Outlook users, aren’t familier with iCal but can relate the RSS with the concept of subscribing. As they are the majority crowd, it might make a commercial sense to ride on the RSS popularity and use this buzz word technology that they are already familier with.

The RSS-Data Flop Show

There was another notable thing that happened along the way. Jeremy Allaire tried to extend this whole concept. The thinking was: why we are focusing on just Calendar information? There is all kind of dynamic info being published on the web everyday such as weather data, stock data, traffic data and so on. Why not define the common standard so we can syndicate these data, not just the blobs of text, over RSS. He came up with the term RSS-Data and thought about including real objects in the RSS feed which were serialized using XML-RPC protocol. It would be nice to have a generic “Object Aggregator” which can collect objects from all over the web and present them in a way that’s appropriate for those objects. For example, displaying objects representing stock prices on a continuous graph, weather in system tray balloon, events in Calendar view and news items in regular HTML view and so on. But most people didn’t liked this idea and there was lots of criticism all over the web. These people believed that if you want to put extra info in RSS feed, just define a new namespace for that data and extend the RSS as the original spec suggests. Putting those XML-RPC objects in RSS destroys its simplicity. Eventually RSS-Data thing never really took off although every now and then some guy would re-invent it and bring it up once in a while. If you think about it, Allaire essentially re-invented a form of Web Services with the difference that the idea was far less capable and didn’t had vast amount of infrastructure support that is already available for web services. Why would I publish my weather data objects in RSS feed when I can expose them through popular web service standards? As you might guess, any RSS-Data talk is destined to die out because of enormous popularity of web services.

So What’s The Solution?

Where do we stand now? How do I publish my event info so people can aggregate them in their calendars? In my opinion any type of RSS extension is not the way to go. Almost every other website owned by some group or organization currently publishes some kind of event listing but the thing is that the vast majority of these websites are poor man’s websites; most of them don’t even have regular RSS. Trieng to Implement event subscription using RSS extensions means convincing lot of people to write lot of code. It’s two sided sword: Publishers need to upgrade their code and/or webserver technology and consumers need to upgrade their RSS aggregators. This is expensive affair and taxes both the publishers as well as consumers. As you can see, all these makes the chicken-and-egg problem worse than it is already. If you dump RSS extensions, you are left with the alternative of using iCalendar files directly just as the Apple’s iCal app do. In my opinion, this is the strongest contender for the price because a huge content of over 200,000 event calendars is already available in this format. You don’t have to wait until the people gets interested and start creating the content. The community is already out there. Also this option is least expensive for both publishers and consumers. Any website owner can easily create iCalendar files using free programs such as Mozilla Calendar. All they have to do is to just FTP them on their webserver. On the client side, the consumers can use the same free programs to import event calendars and keep polling websites at regular intervals for updates. Works flawlessly.

Then Why Are We Stuck?

There are quite a few programs available that can lets you at least import (if not truly subscribe) either iCal or RDF formats. These programs also lets you add an event details with their user interface and export it as iCal. The bad news is none of these programs (at least no freeware) available on Windows really “just works”. Many are also not optimized to function as calendar aggregator. Sure there are web-based apps such as iWebCal but I believe, as long as calendaring apps are concerned, I really need a desktop app. Only desktop app would lets me do such things as setup reminders and carry my entire schedule with me offline. Let’s briefly look at four major programs available on Windows: Mozilla Calendar, Win Dates, Events and Microsoft Works. Now Mozilla Calendar truly sucks. Besides awful looks, it doesn’t even have working subscription or publishing capabilities. For instance it neither provides a way to manage subscriptions nor does it lets you select multiple events and export them. Next Win Dates does a good job but it’s commercial. In my opinion, convincing companies, organizations and non-profit groups to buy a software is more painful then copying event info manually in my calendar. EventSherpa had a good start and received lot of praises but suddenly the whole thing has disappeared. And finally, MS Works is just too much bloated to be used as calendar aggregator and of course it’s a commercial product. Because of all these, 90% of users (ahh, Windows users), neither have awareness nor capability to easily share, publish and subscribe to calendar data. This is also the major reason why it has only became moderately popular among websites to put the event listings as iCal or RDF calendar feeds.

Conclusion

We looked at various major standards that enables exchanging calendar information. We also reviewed how iCal is already being popularly used to publish and subscribe event information. We concluded that the efforts towards extending RSS for publishing event information is prohibitively expensive for publishers as well as consumers. We finally reasoned that the calendar subscription technologies really haven’t become popular primarily because of lack of awareness among Windows users which in turn could be attributed to the astonishing absence of quality free calendaring software that runs on Windows.

Thanks

To Gordon Fowler,

Don Faulkner, Michael Fagan, Dan Brickley and Danny Ayer for their extremely helpful comments, suggestions and corrections.