OK, summarizing, this is the feedback from the project:
----
4.1.8 "LDPR server responses must use entity tags (either weak or strong
ones) as response ETag header values.": I do not remember the concrete
resolution of this issues, but I'd prefer to say SHOULD until a standard
ETag calculation would be specified. And this would be aligned with
4.4.2 too.
4.2.3: Here I miss a reference to RFC 2616 Section 12 (HTTP/1.1 Content
Negotiation).
4.4.1: We still think this would be ignored by many implementations,
since mixing metadata about the resource itself and the server status
could be a potential conflict, specially because DC Terms is wide-spread
and used in many applications. Anyway it is fine for us to keep the
"MAY" there.
4.9: Beside the simple linked list structure for linking pages, maybe
could be also added there something like "The page resource
representation MAY have triples with the subject of the page, predicates
ldp:prevPage, ldp:firstPage or ldp:lastPageof and object being the URL
for the respective pages."
4.9.2 I think custom page size is out of the spec, so I'd add something
"Page size MAY be decided by LDPR servers". The same could be applied
for the name of the parameter to retrieve concrete pages: p, page or
whatever.
5.3: Personally I find the explanation a bit difficult to read and
understand. But since I have no better proposal, I'm fine with it.
Maybe, adding a new paragraph saying something like "LDPC results
ordering MUST be as defined by SPARQL SELECT’s ORDER BY clause
[SPARQL-QUERY]" would allow to simplify some of the point in that section.
5.3: What about adding something like "The Client MAY specify the object
for ldp:containerSortCriteria and ldp:containerSortCriterion."? The
question is how.
5.3.1: I'd change the link to the example ("as in the example") to refer
the concrete example, I think example 6. Currently does not work when
printing.
5.4: For a non-LDPR POSTed to the LDP server, the server may create a
corresponding LDPR. The non-LDPR may Link (HTTP-Header) to it's
associated LDPR using the "meta"-relation - why not add the also an
inverse Link (HTTP Header) using e.g. the "content"-relation?
4.10 & 5.10: We may need more thinking about this feature. It is a cool
idea, but again mixing resource and server status data. In case of
having more open questions about this, I'd prefer to keep out.
----
If there are no more additional comments, I'll send them to the WG later.
Let's see if we have time after the holidays break for addressing the
implementation. I'd need to take a look to the current status of the
test suite for that.
Cheers,
--
Sergio Fernández
