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.
“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.”
CalDAV?
Jens, I agree that part of this post is not very clear. I was rather aiming for something that allows a site to advertise to the user that it has calendar data, and also allow the site (under certain circumstances) to synchronize the local data. To do this with caldav, the site needs to run a caldav server.
I’m looking for something easier to implement for site owners. Not every site owner wants to or can run a whole caldav server, just to advertise a few events.
I’ll update this post soon to explain a bit more elaborately.
A CalDAV server is a WebDAV server, so the events can be obtained in iCalender format files by issuing GET requests.
As I already wrote on 09 November 2010 in my comment to ‘Bringing your Calendar to the Web, Part 1’:
For individual events, I suggest that the Lightning team :
– Explains to the webmaster of each major web site displaying events that each displayed event should be a link to an ICS file,
– Permits to drag and drop this event to any Lightning calendar in order to import it immediately inside this Lightning calendar.
Why reinventing the wheel? There are ICS files and CalDAV servers but no release 1.0 from Lightning. Please focus your efforts on the client side.