Re: collections

> > Is there one 'collection' Atom Feed for APP use, and one normal
> > Atom Feed for subscribers?  In other words, is the collection
> > URI also the Atom Feed URI?  If not, it would be nice to say so
> > and to say why not. I don't see any reason for two URIs but
> > would like to see arguments for it if so.
> >    
>
> In the simplest case: one collection, producing one subscription.
>
> It is also entirely possible for multiple subscription feeds to be produced
> from one collection, such as category subscriptions.
>
> Further, it is entirely possible for there to be multiple collections which
> end up being published as one subscription feed. Think collections of
> entries, photos, reviews, caldav events ... all surfacing as one "my blog"
> subscription feed.
>
> And of course combine the two.. it's possible for multiple collections to
> provide piecemeal input to multiple subscriptions.
>
> Also note, and this is interesting, one might have an entries collection
> managed by your blog provider, but the photos collection could be managed at
> flickr ... and both being combined into a subscription feed. Thus two
> completely different back end server systems for collections.
>
> e.
>
>  
Thanks very much for this excellent reply.    :-)

So excellent, in fact, that I think the text should appear in some form 
in the spec! Surely this kind of thing would be helpful to future 
implementors?  It's completely cleared up this issue for me, and I'm 
sure others will be asking similar questions. 

If I could extend and summarise your points a bit:

"A Collection takes the form of an Atom Feed (modulo paging and 
draftness - and if there's others, it would be good to list them here), 
but is oriented towards editor clients, not subscriber clients. There 
may or may not be a one-to-one relationship between APP Collections and 
public Atom Feeds. Collections are generally secured where Atom Feeds 
are generally public".

Surely making these points explicit will help readers? (Have I 
paraphrased correctly?)

Now, do Collections normally just contain URIs of Entries, or the full 
content?  I believe it is redundant to return the full, or even 
partial/summary, content, but the spec hints that content of some sort 
may appear: clients 'SHOULD perform a GET on the member resource before 
editing' (sec 9.).

Indeed, can I boldly suggest that the spec explicitly says the 
collection feed 'SHOULD NOT' have any content - because such content has 
not got a specific purpose in the APP world?  A blog publishing client 
can fetch each entry it hasn't cached and save network bytes in the 
process (perhaps setting a standard for feed readers to follow!). As I 
mentioned in my email, an example in the spec of what a typical 
Collection feed might look like will help enormously.

Which leads me on to another point I was hoping to clear up in my mind: 
on what URI does the client 'perform a GET before editing'? Is the 
'edit' URI/link-rel synonymous with 'member' of a collection which is 
synonymous with 'full editable form' which is synonymous with 'provided 
in the Location header on create'?

In sec 8.1, it states 'Clients MUST NOT assume that the URI provided by 
the Location header can be used to edit the created entry'.  Yet the 
examples consistently show the Location: URI being the one with 'edit' 
in it, that is then also duplicated in the link-rel-edit URI.  When 
might they differ? Indeed, when are any of the above-listed synonyms 
broken? If there are any, they should probably be explicitly documented 
so people like me don't get confused.. :-)

Another minor issue I asked about before is the use of 'edit' in the 
URI: if this is the XML/Atom form of an HTML Entry page, surely it 
should have a URL like:

 http://myblog.com/postings/what_my_cat_did_today.atom

for the Atom equivalent of the HTML page:

 http://myblog.com/postings/what_my_cat_did_today.html ?

If there's some concept I've missed that means this is wrong, please 
explain, otherwise please confirm that the use of 'edit' mid-URI is 
arbitrary and even perhaps .. misleading or inappropriate?

Finally (sorry to use up attention credits!), why is there link-rel-edit 
at all once we're in APP-land?  I can understand having this to point 
from HTML to XML (as originally conceived by Joe Gregorio in 
'Deconstructing the AtomAPI', back in 2003 - yes, I have been doing some 
APP archaeology!), from public Atom feed to APP member/entry, and from 
APP Collection to its members, but why duplicate these links in the XML 
of the entry itself?  Indeed, Collection->Member/Entry should perhaps be 
link-rel-member?!


Once again, thanks for your clear and non-hostile response!  :-)  I am 
actually happy that asking questions like this can help firm up the spec 
and make its life much longer - as long as I get answers, some of which 
are followed by clarifications in the text....


Duncan


_________________________________
Duncan Cragg
http://duncan-cragg.org/blog/