Comments on LDP TR http://www.w3.org/TR/2013/WD-ldp-20130730/

Hi,

I've been reading the LDP last call draft,
http://www.w3.org/TR/2013/WD-ldp-20130730/

(Note that I am reviewing this as a developer, not as W3C Director,
though I may be a developer who has a shrewd idea of the sort of
things the Director might approve of.)

I have comments at various levels.   Two things concern me mainly,
firstly that the LDP platform will support the functionality
which the RWW community has been using, including tabulator-based 
apps, and the second if that the platform in general provide a 
in interoperable functionality between compliant client and server.

This last is threatened mainly by the huge number of SHOULD's 
for the server where I would have expected MUSTs to get 
interoperability, and a persistent theme throughout the spec
the actual behavior a client or a server can expect of the other party
relies completely on out-of-band agreements.
To the extent that that is true, the document does not define an interoperable system.

I'll go though in document order now.

4.1 "burden of constraints for resource creation"  - I feel that phrase needs more explanation

4.2.9  This is an example of a complete interop gap.   The server might or might not mess with your triples in any way defined elsewhere. 
I suggest defining a clean simple high-interop version of the server in which the server doesn't mess with or constrain the client application at all.  This is a really important use case.  For the RWW world, LDP storage must be generic storage which be used with any app.   Maybe we can make a profile of this spec for this case, with no domain knowledge or behavior in the server.  If not, we have a problem.

4.2.10  "Conservative clients"?? you already have MUST and MAY, but now (and elsewhere) you have conservative (and presumably liberal) clients.    If you want to create a new conformance class Conservative Client, by all means do so, but declare it in the Conformance section and SAY WHAT YOU GET from each level of conformance.    A client is not an animal tiptoeing gingerly or not into the wide world out there, it is a small hard part of a machine which either works or doesn't work.  The phase occurs elsewhere too.  It is a red flag. (Why would a client want to be conservative? What is risked by not being?  What would a liberal client do? Does this mean the server needs to be more specified to eliminate the risk)

I would strongly support as an exercise looking at a version of the spec with everything which is not mandatory removed, and see what you end up being able to do with it.

4.3.4.  Broken.  No guarantee that anything will work. Suggest strongly the following:-

LDP Clients MUST either give no accept header or must give a header which includes 
at least text/turtle and has NO OTHER mime type with a higher  q.

LDP servers, which a GET is received on a LDPR, if text/turtle is present and there is no other mime type with a higher q, they MUST return turtle.  If there is no Accept header, they must return turtle.

Protocol value: If a LDP client goes a GET it will get the data in turtle.  Interop is achieved.

This provides interoperability and also is compatible with HTTP.
It allows existing conneg software to be used, and allows LDP to work within a general conneg-based server serving other things too.


4.5.6.  You allow servers which do not support PUT or PATCH or POST.  Why?   A client using such a server will have no write  ability at all, and so your spec as a protocol delivers zero value on top of HTTP GET.  Suggest change all to MUST, or make two levels of server,  one which supports PUT and PATCH and no collections, and one which supports everything.

4.5.2  Same sort of problem.  Are you preventing data loss or not?  Suggest yes. Clients MUST use If-match and Servers MUST implement it (which may men ignoring it in a case where you know nothing else can change the data).   Protocol value: Changes from others are never overwritten.

4.5.4  A server which throws out random triples is hard as a basis for RWW applications.  We must have a profile in which the server has no domain knowledge.

4.5.6 MUST allow PUT.  Otherwise, what is the point?  

(Note that for clients which use PUT To make resources in system that looks like a unix file system, servers will have to generate intermediate directories.
It is very useful for servers to be able to map a unix-like file system, for many reasons, including the isomorphisms between remote and local storage.  So the use case in which the LDP server is a big unix file system but with PATCH as a performance enhancement is important.  This doesn't affect the spec in any normative way I can see.)

In this case, objects are not made by POST to a collection, but being mentioned in a a new file with PUT and then later PATCH.

Those are comments on the first 9 pages.  I have marked up the other  24 pages as well, and the type of remark is fairly similar.  I'll send these now.

Keep up the good work

Tim BL