W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > May 2011

Comments on Graph Store HTTP Protocol (20110512)

From: Simon Johnston <simon@johnstonshome.org>
Date: Thu, 19 May 2011 12:36:27 -0700
Message-ID: <BANLkTimV3p0n12jEV9w9FH9Cp_EVrFSjUA@mail.gmail.com>
To: public-rdf-dawg-comments@w3.org
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.

2. In section 5.3, I would be more explicit on the use of "overridden"
perhaps with an example, does this mean a user can forbid a resource
to be deleted, or can see pending deletes and reject them, or later
"undelete" a deleted resource?

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 Location response is optional where a URI is
provided and required where it is not (as per the current text).

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.

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).

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.

Otherwise this is very clear and well organized.


Simon Johnston (simon@johnstonshome.org)
Received on Friday, 20 May 2011 06:56:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:11 UTC