- From: Joe Ross <joeross@us.ibm.com>
- Date: Fri, 18 Apr 2014 10:29:06 -0500
- To: public-ldp-comments@w3.org
- Message-ID: <OF5CE66CF6.126EF9DF-ON86257CBE.005507EF-86257CBE.0055101E@us.ibm.com>
This seems like a good specification, and I don't see any major problems with our implementing it, assuming some of my assumptions are correct (see below). I do have a few comments and questions: 4.2.1.4 Since an LDPR can be an LDP-NR, and the header must be included responses to HTTP requests for all LDPRs, the following statement seems incorrect: "The presence of this header asserts that the server complies with the LDP specification's constraints on HTTP interactions with LDPRs, that is it asserts that the resource has Etags, has an RDF representation, and so on, which is not true of all Web resources served as RDF media types. " 4.2.1.6 An example would be useful here... 4.2.4.3 Server-managed properties are non-modifiable, and these can be ignored, so this seems to contradict 4.2.4.1. Perhaps this needs to be qualified to exclude ignored server-managed properties. 4.2.4.4 Does the PUT succeed in performing an update in this case? Should all requests with 4xx responses be assumed as having failed? Seems that it would be more consistent if info was returned using describedBy link header as mentioned previously for constraint violations. 4.2.6 HTTP HEAD According to HTTP 1.1, "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response." There is no mention of OPTIONS, so why is OPTIONS mentioned in the context of HEAD? Also, why not explictly say that HEAD MUST include the same headers as GET, so clients can safely assume that. These comments also apply to 5.2.6 HTTP HEAD. 4.3.1.3 I don't understand this statement. "... MAY have an rdf:type of only one of ldp:RDFSource ..." . Seems there is something wrong with this sentence. 4.3.1.14 This seems like a good statement to make, and it should not be at risk. 4.3.2.1 Shouldn't this say something like "... MUST provide a text/turtle representation of the requested LDP-RS, unless otherwise specified via the Accept Header"? 5.2.3.2 It appears that there is no requirement that ldp:contains be included in responses to GET requests, which is good, since in our case that would result in doubling the size of the container resource, and doesn't provide any useful information to clients. 5.2.8 HTTP OPTIONS There is an indication of additional HTTP OPTIONS requirements for LDPC, but none seem to be described. 5.2.8.1 This doesn't seem to have anything to do with HTTP OPTIONS. Why is it a subsection under HTTP OPTIONS? 7.2 Prefer header and return=representation I assume that the default representation could omit the containment triples, unless they are explicitly requested using Prefer header. That would avoid having to double the size of LDPC representations for legacy clients. There is a statement below example 11 that seems to say this: "A server that honors this hint would return (at least) the following response, and perhaps only this (it might well omit containment triples if they are not specifically requested)". ================================== IBM Cloud & Smarter Infrastructure Jazz for Service Management joeross@us.ibm.com
Received on Friday, 18 April 2014 15:50:05 UTC