Re: Last whack at the issues

> <co-chair-mode>
> Here's how we'll do it.  We'll buy into Sam's judgment on what should 
> be closed (so if you disagree, speak up).  For the rest of them, we 
> will review the prior WG discussion of each Pace, so if you're happy 
> with where the WG got to, you need say no more.
> :
> It is our intent to close this discussion on August 16th, produce 
> another draft, do a formal Working Group Last Call (our Area Director 
> has requested this) and, following that, go to IETF last call.
> </co-chair-mode>



I know it's a bit late and you're all looking to wrap this spec
up pretty soon, but I have some questions and observations to 
make, which I have been saving up until I knew more about the way
you work and the history of APP. I'm both a relative newbie to APP 
and a latecomer to the discussion, so I don't expect my comments 
to be wholeheartedly embraced.  :-)

Also, I'm sure much of what I say below has been argued to death in 
the dense threads of the list, so I apologise in advance where this 
is true. I tried tracking down discussion on a couple of my points,
but failed to navigate the thick undergrowth of APP history...

So, please perhaps treat my comments as advance warning of the 
kinds of reactions you may expect to get once you finalise and
publish this protocol to a wider, non-list-contributing audience.

If you could see it this way, and not flame me, I would of course
be most grateful!  :-)

I know everyone here wants to produce a protocol they're proud to 
hold up as a great example of good engineering.  I personally 
want to be able to hold up the APP as a great example of how to do a
REST protocol. I don't want to have to qualify my enthusiasm...

So, here goes...


[All comments WRT draft 09]


Differentiating APP from 'Web' Service models
---------------------------------------------

When I first came across the APP, I was disappointed that it had
concepts such as introspection, discovery and service - all rather
non-REST, Servicey concepts - around the Introspection Document.

There is a danger of not differentiating the APP's REST
approach from the Service-Oriented world view that I and many
others are trying to distance ourselves from. In fact, we'd
like to use the Atom Publishing Protocol as an example of
how to do it better, without causing confusion by using 
Servicey terms. The motivations of the list are perhaps not
the same as mine..!



Collections
-----------

Why invent new term 'member', for entry and 'collection' for
feed? Alternatively, if collection/member really is a different
thing from a feed - it really is a kind of elemental structural
data type - then why not use it for Introspection Documents: why
not just have collections of collections?

Here, a feed would just be a 'subclass', usage or specialisation
of the 'collection' type.  This Introspection Document could be 
a collection (site) of collections (workspaces) of collections
(feeds). Then one could have a few or as many nested collections
as one wished.

There are just too many concepts in the Introspection Document, 
which jars against the preference towards simplicity we all like 
as REST practitioners and protocol designers. It's also very 
specific to the blog-site use-case. I know that's the whole 
point - and what the WG is tasked with - but this restriction 
is actually unnecessary even in that context.



Collections, Feeds and Entries
------------------------------

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.

Atom Feed Document: is it optional whether this is just a list
of links to entries versus a normal Atom 1.0 feed with content 
included alongside these links?  Could we have an example of a
full Atom Feed Document/Collection, with URIs, if so?

The example URI for getting an entries Collection 
'http://example.org/entries/go' is imperative in style (action
on the URL).  It may be better to use the more declarative form
'http://example.org/entries/' (or
'http://example.org/entries/head' if you really want something
to indicate headness..).

Presumably the visibility of draft Entries is determined
by the auth on the Feed/Collection? Or is this the (single?)
case which justifies a separate Collection (editable) URI to
the Atom Feed (public, read-only) URI?

Why does the Introspection Document declare the 'accept'
mime type, not the collection itself?  In REST, I understood
that the sense of what you could do comes from the thing
on which you intend act (e.g. a form inside a page), not
from a separate resource that points to it.  Again, if the
nested collection approach were used, this would be where
'accept' would go - in the relevant collection itself (in
case there wasn't an enclosing collection to declare it).



Entry Editing: Separate URIs
----------------------------

Why do we need the word 'edit' in the URI? What is the point 
of the <link rel='edit'..> and <link rel='edit-media'..>? 
What's different about an Entry with 'edit' in it compared 
to one without?  What's the point of having a separate 'edit' 
URI? 'Clients MUST NOT assume that the URI provided by the 
Location header can be used to edit the created entry' - why 
not? Isn't that the REST way? Shouldn't then the Location: URI 
differ from this 'edit' URI, if you need it? What if you GET 
the 'edit' URI?  '.. SHOULD perform a GET on the member resource 
before editing' - on which URI? the 'edit' one?



Thanks for listening - I hope what I'm asking makes sense, and 
someone kind will reply in an informative, flame-free way!! 

Cheers!

_____________________________________

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