Correct, no standard interpretation for this at the moment, but it's a pretty common solution to this problem (seen in several presentation about the limits of AtomPub). I use rel="service" currently for auto-discovery of AtomPub Service Document in HTML link tags too. If we extend feeds and enable them to describe collections too, should we use rel="service" for these feeds or limit this rel value strictly to service documents ?
2009/5/11 Nikunj Mehta <[email protected]> > Thanks James. > > 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. > > Nikunj > > On May 11, 2009, at 8:47 AM, James M Snell wrote: > > 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 >>>> >>>> >>>> >>>> >>> >>> >>> > > > Nikunj R Mehta | Consulting Member of Technical Staff | Phone: +1 650 506 > 0679 | Blog: http://o-micron.blogspot.com > Oracle Advanced Development Projects > 500 Oracle Parkway #4OP662 | Redwood Shores, CA 94065 > > Oracle is committed to developing practices and products that help protect > the environment > > > -- Hadrien GARDEUR http://www.feedbooks.com - Co-Founder Cell: +33 (0)6.63.28.59.69 http://twitter.com/Hadrien
