Re: Comments on Graph Store HTTP Protocol (20110512)

Simon, thanks for the feedback, see the response (inline) below. The changes have been incorporated into the editors draft [1].
> Having read the latest draft I have a number of comments, though none I believe substantial.
> 
> 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.
> [...] 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.

We have determined that 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)

[1] http://www.w3.org/2009/sparql/docs/http-rdf-update/

Received on Wednesday, 16 November 2011 02:45:45 UTC