So google has released the first mainstream implementation of the Atom Publishing Protocol (APP) for something other than blogging, Google’s new Calendar API is APP based. The question that everybody is now asking is “did they do it right?”.
Joe seems to think so, his main criticism seems to be about their security model, Elias is a little more critical and James seems to like it…….. so far. The one thing that seems very wrong to me is that they have produced yet another standard for calandering. I now have lots of questions and no real good answers, could this be done better?, can it reuse the existing calendaring standards? how does any of this relate to CalDav, is that DOA? and finally how should arbitrary applications extend ATOM for their api?
I am a big big fan of the Atom Publishing Protocol, it seems lightweight, easy to implement and “shines a light for best-practice REST“. However, its extensibility model is still getting worked out. Google’s extensibility approach uses the same extensibility model utilized by all the RSS extensions, e.g. Apple’s iTunes and Yahoo’s Media Extensions. The approach is to define new xml elements and namespaces and then sprinkle them throughout the feed. While this works it doesn’t seem to be leading to much interoperability. ATOM however has been defined to carry arbitrary payloads (RSS can only carry HTML inline) and so it should be able to play nicer with exiting standards. ATOM can, for example, carry iCalendar or xCal inline, and either of these payloads feel like a more interoperable solution for Google’s calendar api.
There seems to me to be a bigger issue lurking here, namely, what is the ATOM Publishing Protocol for? At the moment I see a spectrum of answers ranging from “it allows any blogging client to talk to any blogging server” to “it is a universal api that can be used for modeling anything, think of it like SOAP, is just an envelope”. Google is clearly leaning towards the latter, whereas the charter describes a means to edit “Weblogs, online journals, Wikis, and similar content”, is a calendar entry similar to a weblog?, is a purchase order?.
Practically speaking, this seems to boil down to whether there is a universal ATOM client? i.e. an ATOM client that can talk to any ATOM server. Google doesn’t think so (when posting Calendar entries the <gd:when> element is required), however, the ATOM working group has been running “interop testing”, so it should be possible????? Confused yet? As best I can tell ATOM clients best option is to discover the types of things that can be posted to a collection and decide whether or not it is equipped to post. In the current draft this is not really possible, but this is about to change. James has proposed an excellent set of changes that look as though they will be adopted in the next revision. They outline a means for servers to advertise the media types that they accept in collections and the ability to have ATOM entries automatically associated with the posted media. So a client could detect that a specific collection accepted “text/calendar” and then post an iCalendar file. This seems like a nice approach, that google et al could / should consider. It works very well as long as the objects being posted have defined media types.
There are still, however, a couple of interop problems. What instead would happen if we wanted to post purchase orders? or rob’s foo objects? These objects don’t have media types so how does a server advertise that it accepts them? Another problem is how a server advertises the extensions it supports in Atom Entries. A collection can only advertise that it accepts ATOM entries, but how does it communicate to the client that it accepts the “threading extension” or xCal in the entries <content> field? This seems fairly important.
The Atom Publishing Protocol is gaining momentum and google’s data api is only going to help that. The real test for ATOM now is understanding how to extend it and how to extend it in a fashion that builds on and reuses existing standards. That’ll be the key to true interoperability.