Overall I think this is good... a few nits tho...
Joe Gregorio wrote:
>[snip]
> == Proposal ==
>
> In Section 5.2 Creating a Resource
>
> Replace
> {{{
> 2. If the Member resource was created successfully, the server
> responds with a status code of 201 and a Location: header that
> contains the URI of the newly created resource.
> }}}
> With
> {{{
> 2. If the Member resource was created successfully, the response
> MUST include a Location: header that contains the Member URI of the
> newly created resource.
> Note that creating a resource in a collection may in fact create
> more than one resource and those resources may be accessed by many
> different URIs, all of which has no impact on the fact that only
> one Member URI is added to the collection.
> }}}
>
Change to "If the member was created successfully, the response MUST
include a Location: header containing the Member URI of the newly
created resource. Note that creating a resource in a collection may
result in the creation of additional resources accessible via URI's
other than the URI associated with the collection."
>[snip]
> To Section 5.3.3 Deleting a Resource change
>
> {{{
> 2. Upon the successful deletion of the resource the server responds
> with a status code of 200.
> }}}
>
> to read
>
> {{{
> 2. Upon the successful deletion of the resource the Member URI no
> longer appears in the collection. Note
> that it is possible that mulitple resources were created when this
> member was POSTed to the collection
> and those resources may still exist and be accessible via other
> URIs, all of which is beyond
> the scope of this document.
> }}}
>
Change to "Upon the successful deletion of a resource, it's Member URI
no longer appears within the collection's feed documents. Note that,
because it is possible that multiple resources were created when the
member was POSTed to the collection, those resources may continue to
exist and be accessible via other URI's following the DELETE on the
Member URI. How such additional resources are deleted is beyond the
scope of this document."
>[snip]
> Section 9 Listing Collections
>
> Change
> {{{
> Collection resources MUST provide representations in the form of Atom
> Feed documents. Each entry in
> the Feed Document MUST have an atom:link element with a relation of
> "edit" (See Section 10.1).
> }}}
> To
> {{{
> Collection resources MUST provide representations in the form of Atom
> Feed documents. Each entry in
> the Feed Document MUST have an atom:link element with a relation of
> "edit" (See Section 10.1). For
> an Entry Collection the URI in that atom:link element is the entries
> Member URI. For Media Collections
> the Member URI appears as the value of the "src" attribute of the
> atom:content element.
>
Change to: "Collection resources MUST provide representations in the
form of Atom Feed Documents. Every modifiable entry in the Feed
Document MUST have an atom:link element with a relation of "edit" (See
Section 10.1)..."
> A resource is considered a member of a collection if it has a Member
> URI that appears
> in a collection, that is, the URI appears as a Member URI in one of
> the paged feeds
> for a collection.
> }}}
>
I'm not sure this last bit is at all meaningful. Every entry in a
collection's feed represents a member. Some members may be modifiable
(e.g.they have edit links / content src) or they're not.
This raises yet another point about media collections, btw: how do you
indicate a nonmodifiable media collection member? For entry
collections, one could simply omit the edit link. No edit link, no way
to modify. With media resources, however, we cannot omit the content
element.
- James
