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

Mostly agree on all below. Just a couple of points as I was reading it.


On 22 Aug 2013, at 14:27, Tim Berners-Lee <timbl@w3.org> wrote:

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

Would that PUT be useable for creation of resources?
I'd rather have collections, than PUTs that create resources.

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

I think we don't need two profiles here.

We just need to specify a relation that specifies what types of graphs can be POSTed to an LDPC. 
We don't even need the vocabulary for the types of things to be determined yet - that can be done 
by an RDF-Validation group such as the one being set up by

  https://www.w3.org/2012/12/rdf-val/

All that is needed is that a client know that if it does not know the restrictions on the POSTs
that it should not be surprised to get a refusal. So if an LDPC on a GET returns

<> a ldp:Container;
   ldp:restriction foaf:PrimaryProfileDocument .

Then unless the client knowns what the foaf:PrimaryProfileDocument restricts then it MUST not POST
there. It would be interesting to work out if inferencing can help it here to go from some vocabulary
it knows to


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

I think PUT is just an expensive PATCH. I suppose HTTP does force us to accept PUT as a way to 
create a resource. The problem with PUT for creation is that one does not know if one is not
overwriting a resource that allready exists. ( see point you made above on If-match - do we need
an If-Not-Exists? )

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

yes, the advantage of making intermediary directories is nice.

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

Social Web Architect
http://bblfish.net/

Received on Tuesday, 3 September 2013 14:30:54 UTC