Re: Updated Protocol draft available

Rob,

I've read through the spec, a few comments below. None of these are show-stoppers, most of them are minor, editorial comments. In other words, in advance to the CFC, I definitely vote for a FPWD publication as soon as possible.

Thanks!

Ivan

Comments:

- End of introduction, terminologal issue: third bullet items refers to "hosting system", whereas in, eg, 1.1 we refer to clients and server. This is also the term used in the terminology section. Shouldn't we use "server" instead of "hosting system"?

- Editorial issue: I think it is worth the trouble (at some point, not necessarily in the FPWD) to add explicit links into the LDP document for terms like Containers, Basic Containers, etc. A reference to the HTTP header entries (mainly the not very well known ones, like 'Vary') may also be useful.

- I think it will be worth adding a separate section listing the additional constraints, with a reference back to the place where it is defined (I beleive respec gives neat tricks to do that).

- Section on 'Paging Responses', first sentence, reference to [ldp-paging] is missing.

- Shouldn't it HTTP in responses include the '; profile="http://www.w3.org/TR/annotation-model/jsonLdProfile"' with the 'Content-Type: application/ld+json' header?

- If an annotation is deleted, per http://www.w3.org/TR/ldp/#ldpc-HTTP_DELETE, the reference to that resource is removed from a container; I think this is worth repeating in the text. Let alone that fact that if this happens, the URI-s the client has for the container pages may change and even become 404-s in case the last page contained a single resource which is the one deleted...

- Still with DELETE, it is not clear what really happens with the resource itself. Pragmatically, what should the server respond if a GET is issued with the URI of the deleted annotation. The LDP document forwards to the relevant RFC: https://tools.ietf.org/html/rfc7231#section-4.3.5 which actually leaves this issue open. Should we keep it open, or should we define what should happen in such case (possibilities are to return a 404, or a 204 (no content). I have not made up my mind on this, just flagging the question. (I am mildly in favour of 404, although I do not like the fact that a URI, ie, the URI of the original annotation, is still around and would lead to a 404. On the other hand, if it is not a 404 then it would suggest that the URI can be reused through a PUT, which may not be a good idea and it would also force the server to check whether the resource is listed in the container.)




> On 18 Jun 2015, at 02:07 , Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> Changes include especially clarity around 4.1.4 and added section 5 on Error conditions.
> Other minor tweaks and typo fixes.
> 
> http://w3c.github.io/web-annotation/protocol/wd/
> 
> Comments welcome as always and CFC to publish as FPWD coming soon
> 
> Rob
> 
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704