Disposition of comments for the Linked Data Platform (LDP) Working Group

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.8 PATCH is optional. Suggest a MUST. PATCH is to first order the only thing LDP provides over WebDav.


4.8.2 MUST

Suggest specify a the subset of sparql-update we use at the moment as a mandatory patch format to get basic interop, with possible later extension to other languages.


*******

Something I mentioned in a mail a long time ago is the necessity of doing
atomic flag (P/V) operations with a PATCH.

To recap, you have to be able to do a form of DELETE triple(s) which will FAIL
and prevent any corresponding INSERT from happening. This is top be
able to allocate shared resources.

Eg DELETE { :x :nextID 4 } INSERT DATA { ?x :nexID 5 }.

Hmm. Maybe this is covered by the ETag system sufficiently.
If so, the case should be given as an worked example and put in as a test case.
A collaborative system which allows atomic flag setting is fundamentally more valuable
than one which doesn't.

4.9.1 Servers must support the OPTIONS method. Why? Should there be a basic level
of functionality which any LDPR allows and which does not require OPTIONS polling?

OPTIONS is expensive: another round trip.

Always avoid an extra round trip if you can.
We need this system to move really fast.
Round trips show up as user interface sluggishness, user task inefficiency, and lost/bored users.

Note that OPTIONs is resource-specific. (Unless you use some sort of wildcard extension
or a POWDER label say). You have to do it for every fresh URI you find.

The Linked Data operation is a GET. Is the basic operation for an LDP-capable client always OPTIONS, GET, or GET, OPTIONS?

Maybe key headers can be put into the HEAD and GET response.

Maybe the class of resource announced with Link: rel=type
can have a URI which can be looked up itself and cached.
and will give the set of features in a standard way.

Suggest define a core LDP protocol which does NOT use OPTIONS, by assuming that
the core functionality is enough for clients to do what they need.
Clients needing extensions maybe can use OPTIONS. But maybe POWDERR should be preferred.

Hi.

I raised this issue before, but it was never resolved to my
satisfaction, so I'm raising it again now at LC.

Sec 4.6.1 says "LDPR servers must remove the resource identified by
the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET
on the same Request-URI must result in a 404 (Not found) or 410 ".
This is bad because it redefines HTTP DELETE, which already has a well
defined meaning in RFC 2616. The definition in 4.6.1 is more specific
than the one in 2616, and it's why you need the LDP-specific Link
response header which basically tells the client that the 200 response
doesn't mean what it says in RFC 2616, but instead what it says in LDP
1.0.

The correct way to do this is to simply reuse the definition in 2616
so that the client knows nothing about the state of server after a
DELETE has completed. I'm not familiar with the use case that requires
those post conditions on DELETE, but from experience I can't imagine
why a client would need to depend on this specific behaviour. Let me
be clear though, my concern is *only* with the interface between
client and server, not with server behaviour. If you want to define
that LDP servers have to behave in a certain way, go nuts. But as soon
as that information leaks into the interface, you've crossed a line,
leaking implementation details so that the client is coupled not to
the interface, but the implementation.

The same problem with DELETE exists elsewhere in section 4 too,
including with PUT, though the definition seems close enough to 2616
that I'm not sure why it's being redefined.

So in addition to those concerns about section 4, I'm also concerned
with the requirements on client implementations and don't understand
why they're necessary.

Some seem purely superfluous, such as 4.3.5, as it's part and parcel
of the RDF model that resources can have multiple types (not to
mention the open world assumption). The same goes for 4.3.6. 4.5.2
falls under this category too because that behaviour is just one
possible path through HTTP's conflict detection mechanism.

4.5.3 and 4.5.4 seem more like BCPs that anything needing to be
conformance criteria.

4.5.5 just seems like a badly phrased constraint on server
implementation that has nothing to do with a client.

4.11.3.3 says that a client shouldn't invoke GET, really? Are you
concerned about DoS issues like the W3C's DTD problem?
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/
There's no reason to make this a criterion of correct client behaviour
AFAICT

4.11.3.4 also seems like it's part and parcel with the RDF model

In short, I think section 4 needs to be completely rewritten so that it;

- contains no client conformance criteria
- contains no interface conformance criteria

In addition, the mandatory Link header should be removed so that
clients won't be tempted to treat server behaviour implementation
conformance criteria as interface conformance criteria; all LDP
servers would be indistinguishable from Web servers.

Thanks.

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.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.
4.5.7 MUST not SHOULD.

4.6.2 Another totally grey area. When you DELTE a resource, the server may or may not remove triples with that subject from other resources. (When you delete R, any quad R P O R2) may be deleted.
This is ripe for a profile, and in that profile the value of what happens must be explained.
E.G. when you delete R then R is removed from any containers, so there is no C member R
*on this server* or on some other URI region.
This is hairy feature, as of course, as it can't apply to triples stored on another server, so
people splitting data across different servers will get unexpected results.
This sounds like another protocol which needs a lot more thought.
For now, suggest the LDP spec doe snot specify such behaviour, maybe flag magic triple side effects as possible extension spec in future.

[...]

4.10.2.1 "Conservative clients" again. Explain the value of doing this or not doing it.


4.10.2.2 Servers MAY do it. That means clients MUST handle it.

4.10.2.3. MUST

#########################
4.10.2.3 303 lis a basically very unsatisfactory design because of the round trip. As this is a new spec, suggest defined 20X code meaning like a 303 but containing the representation of the thing 303d to. This has been found to a problem in LD. LDP can avoid it now.
Benefit: First page back to user in one less round trip.
#########################


4.10.2.4.3 This design puts the type and next links in the data. I prefer I think using HTTP headers here as elsewhere. Page control stuff is very meta, messy to have it in with actual data.
Not a problem for containers, but for normal LDPRs IMHO.

4.11.1 "LDP does not provide clients with any way to detect whether or not the server is capable of inlining (all its resources or any specific resource), nor does it provide clients with any way to influence which (if any) resources are inlined in any given response." This implies cleints must all be able to handle inlining and recover from it if they didn't really want it.

Need to define a protocol here properly or abandon the feature.

(N3 or one of its weak imitations is obviously a clear choice for a inlined data, as it allows you to preserve the provenance, and basically explain which triples are from which resource. I understand this would frighten people at this stage.)

The spec says nothing about access control.
Give that we are discussing read-write capabilities should we add some words like

“To work with LDPRs clients must be authorized by the server and must have appropriate access control permissions”?

The spec also says nothing about authentication. Should we specify some minimum
level of authentication, for example: LDP servers that require authentication SHOULD consider supporting basic authentication as specified in *[**RFC2617]*** over HTTPS for the highest level of interoperability with generic clients. They MAY also support other authentication methods.

We discussed that LDPCs are a subclass of LDPRs and so containers can be members
of other containers. Do we say that somewhere? I could not find such a statment.
Perhaps we need to add it.

Also, of a container contains other containers, how would ordering work?

Some comments on section 5.1.4 Ordering

1. Why is this section non-normative, given that it defines

ldp:containerSortCriteria and ldp:containerSortPredicate

How does a client find the non-member-property version of a resource R?

4.10.1
"The triples in the representation of the each page are typically a subset of the triples in the resource - same subject, predicate and object." Same triples then? eh?


I prefer the word "inspect" for the way "introspect" is used in the document.
"Introspection" is normally looking into oneself, not into something else.

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