I came up with rel="service" mostly for use with html link tags in order
to bootstrap the discovery of Atompub service documents. It can be used
with atom:link elements but it doesn't provide enough information by
itself to be a complete solution. Putting app:collection in atom:feed
or atom:entry (both of which we've done in parts of the Lotus
Connections implementation) provide the additional bits of information
necessary for a client to do what it needs to do. Both approaches have
their benefits and we've used both.
- James
Peter Keane wrote:
On Fri, May 8, 2009 at 4:49 PM, Nikunj Mehta <[email protected]> wrote:
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.
Hi Nikunj-
I like (2) for the reasons you mention here -- seems to make good
sense. That said, rel=service seems cleaner somehow (perhaps more
loosely coupled?), but does, of course, require more round-trips. One
benefit of rel=service is that it could be easily be included in an
HTML representation (pointing to a service doc for a blog, say).
Also, it seems that l...@rel=service could appear under atom:entry to
indicate where client can post siblings to current entry (I could be
wrong on that assumption...).
Anyway, I don't have a very strong preference otherwise.
--peter
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
