Warning:
This wiki has been archived and is now read-only.
CommentResponse:SJ-1
Link to comment
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011May/0033.html
Status
Not yet sent
Response
Simon, thanks for the feedback, see the response (inline) below. The changes have been incorporated into the [www.w3.org/2009/sparql/docs/http-rdf-update/ editors draft] .
> 1. In section 5.1, in addition to the status codes listed I would add 415 where a clients > issues a POST or PUT with a content type that is not understood by the graph store. > I would also include in this summary the use of 403 and 406 which appear later in the > text. The use of 401 and 403 can be forward referenced to section 6.
This has been changed
> 2. In section 5.3, I would be more explicit on the use of "overridden" perhaps with an > example, [...]
An example has been added.
> 3. In section 5.4, the Location response header is mentioned in the case of POSTing > an "anonymous" resource, however it should be recommended that all POST operations > return a Location header allowing the service to use a different base URI for POST that > for GET/PUT/DELETE.
this protocol, unfortunately doesn't support base URIs.
> This Location response is optional where a URI is provided and > required where it is not (as per the current text).
This is still how it remains, so there is no uncertainty about the full URI of the target .
> 4. In section 5.5, I would like to see the text refer to RFC2616 section 13 for details on > recommended cache-control headers and usage.
This has been changed
> 5. In section 5.6, I would like to see the comments on caching as a distinct paragraph > with reference to RFC2616 for details (the parenthetical comment is incomplete).
This has been changed
> 6. (Additional), I would also like to see the addition of comment on the support for > "conditional" methods, for example it should be a requirement that ALL methods > return the ETag or Last-Modified value of the current state of the resource (with the > possible exception of a DELETE method that returns 202 and has not yet > completed the operation). PUT and DELETE SHOULD require the use of conditional > headers (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or > If-Range) so as to provide > concurrency control on update. The GET and HEAD methods MAY use these values also to allow for the return of 304 NOT MODIFIED.
This would be a big burden on implementations to require this on ALL methods, so I have not made this change.
We would be grateful if you would acknowledge that your comment has been answered by sending a reply to this mailing list.
Chime (on behalf of the SPARQL WG)