From SPARQL Working Group
Jump to: navigation, search

Link to comment


Not yet sent


Simon, thanks for the feedback, see the response (inline) below. The changes have been incorporated into the [ 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 

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)