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 > >
