One of the ongoing themes of my calendar aggregation project is the notion that iCalendar files are (or should be) calendar feeds in the same way that RSS and Atom files are blog and microblog feeds.
As I began to explore this idea, I realized that iCalendar feeds are all over the map in the same way that RSS feeds used to be when there wasn’t a robust, well-known validator. So began a parallel effort to improve the state of iCalendar validation.
I’ve written a series of entries on this topic, based on early observations. Now that curators for the aggregation project are finding more iCalendar feeds in the wild, we’re gathering more data for the validation effort.
Here’s the set of iCalendar-feed-generating software products that has emerged so far:
Google Calendar 70.9054 iCalcreator 2.2.8 FuseCal Software Coldfusion8 Drupal iCal API Intand Corporation//Tandem for Schools Zvents Ical Trumba Calendar Services 0.11.5203 WebCalendar-v1.1.2 Meetup Inc//RemoteApi iCalendar-Ruby
For each city or town participating in the elmcity project, there’s a stats page that reports how two different parsers handle the set of iCalendar feeds collected for that city or town.
The first parser is the currently-available online validator based on iCal4J.
The second one parser is DDay.iCal, the component I’m using to parse and load calendars.
The outcomes reinforce what I saw in the table of results shown here. Parsers sometimes disagree about which feeds are valid, and why or why not.
My hunch is that this isn’t actually a huge problem. I think that as we:
- collect more examples of iCalendar feeds in the wild,
- converge on the complete set of software products that produce those feeds,
- and run all the feeds through the available set of parsers,
we’ll find that there are maybe a dozen or so issues that account for the bulk of the discrepancies.
But that’s only a hunch. To confirm it we’ll need to gather the data and do the testing. If the elmcity project succeeds in finding and cataloging enough of the iCalendar feeds out there in the wild, we’ll have the set of feeds that need to be analyzed.
In parallel, I’ll try to run the data through more than the two parsers I’m currently using. I’m aware of iCalendar.py and vObject and will roll those in as I can. If either of these is available as service let me know, that’ll make things easier. And if there are other parsers that could be included, ping me about them. Again, if they’re available as a service, that’d be ideal.