2006/5/7, Bill de hÓra <[EMAIL PROTECTED]>:
It doesn't rationalize rel="edit-resource". And it needs to; editing non-header metadata about a resource v editing the resource is a first class webarch headache. How many resources are in play with a media entry?
I was thinking about the Atom Publishing Protocol wrt the WebArch, REST, HTTP et al. and this came to my mind: Why couldn't there be a single MemberIRI whatever is updatable? (MemberIRI is given by atom:[EMAIL PROTECTED]"edit"]/@href) * if you PUT an Atom Entry Document and the server doesn't allow you to update the metadata associated with the resource, it will send a 415 (Unsupported Media Type) –or 422 (Unprocessable Entity) if the atom:content itself is of type application/atom+xml (i.e. and is an Atom Entry Document with a different atom:id or Atom Feed Document), which I think shouldn't be supported by the protocol, but, well, that's my opinion…– * if you PUT anything else, you're asking to update the "media resource" (I really hate that name, as it's not another resource, just another representation…), the one which is retrievable at another IRI given by the atom:content/@src attribute. As there would be a single "edit IRI", there's no problem any more about what is affected by DELETE (or eventually other methods such as COPY, MOVE or BIND). I really think The Way To Go is having a *single* resource, with eventually more than one representation (and at least an Atom Entry Document representation), each of which might (must?) have a distinct IRI. The "MemberIRI" would then always be the one of the Atom Entry Document representation. The problem I'm facing is that some fields in the Atom Entry representation might not be editable (e.g. atom:[EMAIL PROTECTED]"alternate"], or imagine if there were atom:[EMAIL PROTECTED]"parent"] referencing the containing collection(s) or atom:[EMAIL PROTECTED]"binding"] giving an alternate IRI for the same resource –both parly similar to D:parent-set/D:parent of WebDAV Binding Extensions [1]–) while others are. How is the server supposed to behave if the client PUTs an entry with updated values for those read-only fields (or additional values, or without those fields)? A simple answer would be "ignore the new values" (annoying if those changes were intended by the end user) or "reject the request with a 422 (Unprocessable Entity)" (can lead to big interop problems if those changes are not from the user but its client software). A 207 (Multi-Status) would work but is not really "simple" (clients needs to parse the WebDAV multistatus response format), except if the rejected changes can be integrated into the Atom Entry response body (which would then be mandatory for 207 responses), but it seems to me that it violates REST: rejected changes are not part of the state of the resource but relate to the request/response pair only and its intended action; however, HTTP doesn't dictate that the entity returned in response to a PUT has to be the updates resource representation, so that might be OK after all… How are people on the WG dealing with this? [1] http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html -- Thomas Broyer
