Cosmo Feed Protocols

The feed service is based on the Atom Syndication Format (RFC 4287) and the Atom Publishing Protocol (Internet-Draft).

Existing Atom-based Content Protocols

There are a couple of existing attempts to build content sharing protocols on the Atom framework: Google's data APIs (GData) and CalAtom.

GData

Google has defined a series of public APIs based on Atom and APP, with some extensions for queries, known as the Google Data APIs or GData. Each GData API provides read, update and query access to a different Google service. GData defines several Kinds of data, including Contact, Event and Message, which are represented as feed entries with XML extension elements containing kind-specific data like start date, end date, and attendee info. GData feed entries never have external content or provide alternate representations of entry content; content is specifically mapped to the main textual property of a Kind - an event's description or a message's body.

Particularly noteworthy is the Google Calendar Data API. Clients use this API to interact with calendar feeds. The API includes the notions of visibility (whether or not a feed is public or private) and projections, which determine the type of information included in the feed (eg free-busy info only, attendees only, events without attendees, and so forth). It also extends the set of query parameters understood by all GData protocols to allow date-range queries, to determine if recurring events should be expanded, and so on. Finally, it defines several XML extension elements in the gCal namespace which provide various sorts of user interface info (color, select state, etc); the most interesting one from Cosmo's perspective is timezone. In addition to Event entries, calendar feeds may also contain Contacts (representing attendees or other people associated with the event) and Messages (representing comments, included within comment-specific subfeeds).

Example

<entry xmlns:gd="http://schemas.google.com/g/2005">
  <category scheme="http://schemas.google.com/g/2005#kind" term="http://schemas.google.com/g/2005#event"/>
  <id>http://mycal.example.com/feeds/jo/home/full/e1a2af06df8a563edf9d32ec9fd61e03f7f3b67b</id>
  <published>2005-01-18T21:00:00Z</published>
  <updated>2006-01-01T00:00:00Z</updated>
  <title>Discuss BazMat API</title>
  <content>We will discuss integrating GData with BazMat.</content>
  <author>
    <name>Jo March</name>
    <email>jo@example.com</email>
  </author>
  <gd:when startTime='2005-01-18T21:00:00Z' endTime='2005-01-18T22:00:00Z'>
    <gd:reminder minutes='15'/>
  </gd:when>
  <gd:where valueString='Building 41, Room X'/>
  <gd:eventStatus value="http://schemas.google.com/g/2005#event.confirmed"/>
  <gd:visibility value="http://schemas.google.com/g/2005#event.public"/>
  <gd:transparency value="http://schemas.google.com/g/2005#event.transparent"/>
</entry>

CalAtom

CalAtom is a proposal put forth by Rob Yates as a way to provide similar features to CalDAV on top of the Atom framework.

Where GData extends the Atom XML schema to provide kind-specific info in the entry document itself, CalAtom provides event content in the xCal representation, either inline or as an external resource. It defines a mechanism for date-range queries that uses a discoverability mechanism rather than a set of documented query string parameters, but that is its only query support. It does not yet address any other client-server interoperability complication (free-busy queries, for example).

Example

<entry>
  <title>Annual Employee Review</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2005-10-07T17:17:08Z</updated>
  <author><name>Daffy</name></author>
  <summary type="text" />
  <content type="application/calendar+xml">
    <iCalendar xmlns="http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt">
      <vcalendar version="2.0" prodid="-//hacksw/handcal//NONSGML 1.0//EN">
        <vevent>
          <uid>20060901T130000Z-123401@host.com</uid>
          <dtstamp>20060901T130000Z</dtstamp>
          <dtstart>20060903T163000Z</dtstart>
          <dtend>20060903T190000Z</dtend>
          <summary>Annual Employee Review</summary>
          <class>PRIVATE</class>
          <categories>
            <item>Business</item>
            <item>Human Resources</item>
          </categories>
        </vevent>
      </vcalendar>
    </iCalendar>
  </content>
  <link rel="edit-media" href="http://example.org/calendar/edit/1" />
</entry>

What This Means to Cosmo

Google Calendar and Mashup Interop

Interoperability with Google Calendar seems like an important feature for Cosmo. We would like for Google Calendar users to be able to subscribe to Cosmo calendars, and eventually we'll allow Cosmo users to subscribe to Google calendars.

Also, it seems like an excellent candidate for simple "mashup" style tools and services to integrate with Cosmo; it's much easier for, say, a Firefox plugin, Greasemonkey script or PHP script to process an Atom entry with simple XML extensions than to parse iCalendar or xCal; these environments already provide simple Atom libraries but don't necessarily have iCalendar and xCal parsers. Similarly, formulating and processing a Google Calendar free-busy query doesn't require a WebDAV implementation like a CalDAV free-busy report would.

The feed service will initially implement bidirectional GData feeds with the Event Kind, the free-busy projection and date-range queries. Visibility, attendee-only and no-attendee projections, and other query variants may be implemented in the future.

Feed Readers

Cosmo's Atom feeds will be also be consumed by programs like standard feed readers like Google Reader, Bloglines, and NetNewsWire, which means that the interesting content of feed entries needs to be available to non-GData-aware programs.

Unfortunately, GData reserves the Atom entry's content element for communicating Kind-specific info (eg event description). Because an atom entry can only have one content element, this precludes the use of the content element for providing other representations of an item's data (for example, an hCalendar variant that would be useful to a feed reader). Atom provides a link element that could be used to point to external representations of the entry, but feed readers don't typically follow those or give users the ability to follow them.

For this reason, the feed service will continue to provide "vanilla" Atom feeds that contain inline hCalendar representations of items and link to external iCalendar representations. It will implement APP for publishing and updating iCalendar representations. The feed service will also provide free-busy projections and date-range queries for vanilla feeds. xCal representations may be supported in the future.

CalAtom

No significant work has been done on CalAtom since Sep 2006, and it's really just a rough proposal, so while we'll keep an eye on any progress that occurs, there won't be any particular effort in that direction for the moment.