Re: collections

2006/8/10, Duncan Cragg:
> 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".

Eric forgot to explicit one point: a collection's feed representation
could very well be subscribed (i.e. dedicated towards both editor and
subscriber clients).
This will be the case if, for example:
- the collection is not secured (wiki), or if the "subscription feed"
is secured,
- the server has no notion of "drafts"
"Subscriber clients" won't use rel="edit" links, neither probably
paging (in the sense of the atom-protocol, which is different from the
one of the "feed history" extension), so subscripbing to "collection
feeds" isn't a problem.

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

Do what you want.

If your feed is only orented towards "editor clients", then use the
most minimal form you can (rel="alternate" link or atom:content), to
save some bandwidth.

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

There won't be a "typical collection feed". There might be one in the
"bloggy wiki" world, but APP aims at a wider use.

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

If you didn't create the entry (it was created with/by another
client), then you don't have the "Location header on create", you only
have the rel="edit" link, so? ;-)

However, the spec is silent on "loops": the collection feed contains
an entry with an Edit IRI equal to "a", when you retrieve it as an
Atom Entry Document, it contains a rel="edit" link with href="b".
First, should you retrieve that "b" entry? when you retrieve it as an
Atom Entry Document, it in turn contains a rel="edit" link with
href="a", so which one is the Edit IRI? "a" or "b"?

This is not RESTful, but it's the price to pay if you don't want to do
WebDAV ("negotiation" using the "DAV" general header) or having an
<app:editable/> flag in the entry.

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

When you do "optimistic concurrency" à la Google's GData ;-)

For example, the "Location URI" will be, e.g., "my-entry", as well as
the "link-rel-edit" IRI. Then, when you first update the entry, the
"link-rel-edit" IRI becomes "my-entry/1", then "my-entry/2" after the
second update, then "my-entry/3", etc.
At creation time, the "link-rel-edit" IRI could also already be
"my-entry/1" and therefore be different from the Location URI.

However, this kind of "optimistic concurrency" mechanism is really
implementation dependant and the spec should deal with it nor even
suggest or imply it: this is not part of the protocol.

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

Why?

URIs are "opaque", I can use the ones I want.

However, maybe "editing" would be better than "edit"…

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

Because a "media link entry" has to link to the "media resource"…

…oh, well, sorry, this is the rel="edit-media" link…

…isn't the idea of using rel="edit" for both the entry
(type="application/atom+xml") and the "media resource"
(type="…something-else…") clearer?
See http://www.intertwingly.net/wiki/pie/PaceUnifiedEntryEditing, not
perfect, but better (I believe) than the current draft…
…however, the WG seems to disagree…

> Indeed, Collection->Member/Entry should perhaps be link-rel-member?!

This would be a rel="self" link, isn't it?
…but where would the notion of "editability" come from, then?

Creating such a protocol is not easy… it claims (or actually many
people claim it is) to be RESTful while it takes many shortcuts that
break its "RESTfulness"…
The more I think about it, the more I tend to believe that WebDAV is
actually what people need (or actually a "profile", maybe without
COPY, MOVE of MKCOL and with some additions like the ADDMEMBER method,
some "standard" properties in PROPFIND and PROPPATCH –such as atom:id,
atom:title, atom:updated, etc.–)

--
Thomas Broyer