I recently started a series on how to best bring your calendar data to the web. Today I’d like to go into more detail about who would be a consumer of your data, and how this could look like.
There are a few ideas (and even standards) on the web to make calendar data more readable for computers. The first that comes to mind is the hCalendar microformat, which uses the HTML class attribute to mark certain aspects of an event. Unfortunately, the use of this format is not very wide spread, mostly because browsers usually don’t make much sense of this information. The standard works well for sites promoting events to the user, such as local event sites. For example, Yahoo Upcoming uses the hCalendar format. There are also efforts to revive ical-as-xml, also called xCal. This is more centered on transporting calendar data via xml though.
But, as far as I have read, there is no standard for sharing local calendar data with the web. To start off in this direction, we have to differ between active and passive data consumers.
On the one hand there are websites that would ask the user for his or her calendar data so that they could display this data, well integrated into their site. For such sites it would be great to provide a standardized API to access user calendar data. On the other hand, there are sites that won’t use a such API right away. Such sites could nevertheless be integrated with your calendar. Parsing the website and looking for dates could help you in creating an event in your calendar.
Scraping events off a web page can be very complex and its not often clear which parts of the web page really are event data. While hCalendar could relieve this issue, for sites which don’t provide metadata a human is probably still the best to decide. I am working on an extension that allows manually scraping data from an email, this could well be extended to websites too.
Lets go back to web-based calendars for a moment. If you have been using an online calendar like Google Calendar, you have to rely on some sort of integration between those websites. Although some sites like tungle.me offer importing data from Google Calendar, this is not always the case. Also, what if you use a different Calendar? The site owner needs to add and test interfacing with each calendar site, which is not always easy.
The alternative would be a standard, that allows on-line calendars to synchronize its data with your PC, and also define a way for other sites to access this data in a safe manner. This would mean the usual add/modify/delete/retrieve operations, together with a synchronization mechanism. To make adoption as easy as possible, this standard should make use of existing formats and standards as possible. I could imagine xCal being the transport mechanism, together with etags and ctags to improve synchronization.
I will be talking about privacy in more detail in the next part of this series.