Re: Best current practice for collection discovery

Mon, 11 May 2009 09:34:10 -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:

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










<<inline: oracle_sig_logo.gif>>


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

<<inline: green-for-email-sig_0.gif>>
 Oracle is committed to developing practices and products that help  
protect the environment
























					Reply via email to