On 4/4/06, James M Snell <[EMAIL PROTECTED]> wrote:
>
> Overall I think this is good... a few nits tho...
>
> 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."
Updated to:
2. If the Member resource 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 more than
one resource and those resources may be accessible by URIs
other than the Member URI. Even though multiple resources
may have been created, only one Member URI is added to the
collection. How such additional resources are
discovered is beyond the scope of this document.
I kept in the part about only one Member URI being added to the collection.
> 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."
>
Update to
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 following the DELETE on the
Member URI. How such additional resources are deleted is beyond the
scope of this document.
I'm not sure ""appears within the collection's feed documents."" is any clearer
than ""appears in the collection.""
> 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)..."
Right now the spec reads that *every* entry MUST have a link/@rel="edit".
Even if you can't PUT or DELETE to that URI surely you could still use that
URI to GET the full representation, since the spec states that
the entry in the feed isn't a full representation. HTTP has status code
405 Method Not Allowed for a reason.
> > 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.
Again, see above.
> 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.
Several mechanisms have been suggested. I think we are going to have
to wait for some interop pain before we see some movement on a
solution.
-joe
--
Joe Gregorio http://bitworking.org
