On this week’s Innovators show, Doug Day joins me to discuss the new iCalendar validator he has recently deployed on Azure.
The project draws inspiration from the pathbreaking RSS/Atom feed validator originally created by Mark Pilgrim and Sam Ruby. The RSS/Atom validator’s test-driven and advice-oriented approach is exemplary, and the iCalendar validator follows in its footsteps.
The tests, in this case, are iCalendar snippets that are, or are not, valid according to the spec. These snippets, packaged into XML files, form a library of examples that does not depend on the programming language used to run the tests. So although Doug’s validator, based on his open source parser, is written in C#, another validator written in Java or Python or Ruby could use the same test suite.
The advice offered is minimal so far, but I hope will expand as the test suite grows. Sam Ruby observes:
Identifying real issues that prevent real feeds from being consumed by real consumers and describing the issue in terms that makes sense to the producer is what most would call value.
In that spirit, I am gathering examples of calendars in the wild and looking for ways to help Doug add value.
In the podcast we discuss a nice example that came up recently in the curators’ room of the elmcity project. A custom-built calendar contained events (VEVENT components, in iCalendar-speak) with no start or end times (DTSTART and DTEND properties). This, it turns out, is not prohibited by the spec. But reporting no error is unhelpful. The author of the calendar — or of the software that produced the calendar — ought to be warned that such a calendar won’t yield a useful or expected result.
Why would anyone produce such a calendar in the first place? This harkens back to the early days of RSS. Many of us found that we could craft simple ad-hoc feeds in order to leverage RSS as a lightweight data exchange. It was liberating to be able to do that. But hand-crafted feeds, or feeds written by hand-crafted software, were valuable only to the extent they would reliably interoperate. Often they would not. The feed validator, by showing what was wrong with these feeds, and explaining why and how to fix them, was a powerful ally for those of us trying to bootstrap a feed ecosystem.
The iCalendar validator has a long way to go yet. But the road ahead is well lit, and I’m grateful to Doug Day for resolving to travel it.
11 thoughts on “Talking with Doug Day about the iCalendar validator”
RFC2445 is obsolete should be RFC 5545
You’re right. I’ve been saying and writing 2445 for so long it’s hard to break the habit. But as of Sept 2009, it’s 5545.
It’s like writing 2010 for the first time, after writing 2009 so many times. Hard to make the shift!
I used RFC2445 when writing http://feed2ical.appspot.com. I will let you subscribe to feeds in iCal, Outlook 2007, etc.
Here’s an RSS feed in the wild that I think has the problem you mention (DTSTART and DTEND missing).
At least when I run it through feed2ical, that is what I get:
DESCRIPTION:Mon\, 31 Jan 2011 13:00:00 GMT – Mon\, 31 Jan 2011 05:00:00 GMT\N
So as an end user (not programmer), who just wants to get a calendar into google calendar, what do I do? I can find the guy who maintains the website, but what should I tell him: “Please specify the start and end dates in your database/application that creates the feed?”
Thanks for any help (From anyone!).
In that RSS feed the only date info is in the description element. It looks like feed2ical takes date info from the pubDate element. Maybe you could at least get him to echo the start datetime into pubDate? That might be enough.
THanks much. I’ll give it a shot. Was hoping to find Dean Sanvitale’s email address somewhere so I could ask him as well, but he seems to have a good job not leaving it posted anywhere. Thanks again.
I’m Dean. What’s the issue? I’ve only used feed2ical with Apple iCal and Outlook 2007 so I haven’t run into the gcal issue. BTW feed2ical source code is here:
It was a quick hack based on an older quicker hack in PHP I wrote in 2002, which is turn was based on http://www.aaronsw.com/2002/rss2ical.py. It probably has many bugs. If there is an obvious issue I can fix it quickly. Given the inexact nature of dates and RSS, I’m amazed that the site gets around 6000 hits daily from around the world.
If anyone still cares after all this time, I finally got around to fixing the issues with dates that prevented feed2ical from validating and working with Google Calendar. I also put the python source code on github. It can definitely use more cleaning. :)
http://feed2ical.appspot.com and https://github.com/dsanvita/feed2ical