Discovering AtomPub Collections – best current practices

When working with data synchronization using Atom feeds in AtomDB, we frequently encounter situations where we learn about a feed simply through its public URL. However, most feed documents do not provide any indication of whether new items can be added to them. (This is not because of a lack of existing standards but because existing standards are either not well known or are unsuitable.)

Some assume that if a feed is generated from some well known AtomPub server, then it must be modifiable. Of course, specialized AtomPub clients, such as for CMIS, dealing with specific feeds can always use out-of-band communication to figure this out. The problem is that standard AtomPub clients that are provided only a feed URL have no way of figuring out such assumptions.

There are two alternatives:

  1. James Snell has suggested the use of “rel=service” but that tends to notbe present on any of the feeds we see. It is mainly designed for use in HTML pages for discovering AtomPub services.
  2. Section 8.3.5 of RFC5023 specifies the semantics of an app: collectionelement appearing as a child of atom:feedelement. This mechanism is veryuseful to us for discovering whether a feed is modifiable and, if so, how itmay be modified using AtomPub. It helps in situations where there are fartoo many feeds to be enumerated in a service document as well as where animplementation does not use AtomPub service documents. Lotus Connections uses this approach in its feeds (among other non-standard apporaches).

James Snell also suggests using app:collection inside of atom:entry elements. Lotus Connections does this in its feeds. However, per 8.3.5 of RFC 5023 there is no meaning ascribed to putting app:collection in atom:entry documents. So I am not sure it has any standard interpretation at the moment.

The downside of the first approach is that it requires a round-trip to find enough metadata about editing the feed. Another problem is that if collections are programmatically produced, the service/workspace/collection metaphor easily breaks down. This part of AtomPub is the least suitable for application feeds as evidenced by their absence in AtomPub usage within GData, OpenSocial, as well as Netflix APIs.
The downside of the second approach is that it is repeated in every feed document, and hence consumes more resources. Secondly, this approach is a little verbose and wouldn’t be understood at all in HTML documents.

Leave a Reply

Your email address will not be published. Required fields are marked *