Hi folks,
When working with data synchronization using Atom feeds, 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.
Some assume that if a feed is generated from some well known AtomPub
server, then it must be modifiable. Of course, specialized clients
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 this out.
There are two alternatives:
1. James Snell has suggested the use of "rel=service" but that tends
to not be present on any of the feeds we see.
2. Section 8.3.5 of [RFC5023] specifies the semantics of an app:
collection element appearing as a child of atom:feed element. This
mechanism is very useful to us for discovering whether a feed is
modifiable and, if so, how it may be modified using AtomPub. It helps
in situations where there are far too many feeds to be enumerated in a
service document as well as where an implementation does not use
AtomPub service documents.
We have added (2) to the hierarchy-ID [1] as a best practice to allow
those starting without an AtomPub service document. I would love to
hear implementation experience vis-a-vis (1) and other practices being
used in the wild.
Nikunj
o-micron.blogspot.com
[1] http://ietf.org/internet-drafts/draft-divilly-atompub-hierarchy-00.txt
