Subject: Best current practice for collection discovery

From: Nikunj Mehta <[email-masked]>
Date: Fri, 8 May 2009 14:49:14 -0700

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

---

From: Peter Keane <[email-masked]>
Date: Sun, 10 May 2009 18:06:53 -0500

On Fri, May 8, 2009 at 4:49 PM, Nikunj Mehta <[email-masked]> wrote:
> 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.
>
> 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 link@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
>

---

From: James M Snell <[email-masked]>
Date: Mon, 11 May 2009 08:47:01 -0700

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

---

From: Nikunj Mehta <[email-masked]>
Date: Mon, 11 May 2009 09:19:44 -0700

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

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

---

From: Hadrien Gardeur <[email-masked]>
Date: Mon, 11 May 2009 18:38:13 +0200

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

> app:collection in atom:entry documents. So I am not sure it has any standard
> interpretation at the moment.
>
> Nikunj
>
>> 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:
>>
>>>> public
>>>> server,
>>>> those
>>>> [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 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