Specification: Which LDP features are required by Solid

[acoburn]

Section 2.2 of the Solid specification requires (MUST) conformance with the LDP specification. The LDP specification, however, lists many features as optional.

LDP requires that a server support GET, HEAD and OPTIONS.

At what level of support does a Solid server implementation need to implement POST, PUT, DELETE and PATCH? It is worth noting that, via OPTIONS, a client can easily discover which methods a server supports for a given resource (via the Allow response header). It is also worth noting that PATCH is, effectively, an optimization of PUT.

[RubenVerborgh]

My suggestion is to make POST, PUT, DELETE, and PATCH all MUST for Solid; except that of course a server is free to only offer read-only resources, in which case it would not need to support them.

I would also make PATCH a MUST because of concurrent editing use cases.

[csarven]

Need to be clear on "support". Checking for support can be a grey area in that if MUST is given, server's capability needs to be essentially testable. Whether they offer resources as read-only is a separate case and we can incorporate that in the test. For example, the test can offer a check against read-only resources, and when tested as such, all MUSTs would be expected to return a 405 and so it will pass the test, and fail otherwise.

[csarven]

Just so that we document some reasons: an overarching reason as to why methods like POST, PUT, DELETE and PATCH should be required (at some level) for servers to support is that the writing - creating, deleting, updating - capability is central to the Solid ecosystem.

We need the servers at MUST to enable an even ground for clients. I don't think SHOULD will cut it.

[csarven]

I tentatively suggest the following which extends LDP:

Generally:

GET: ...
HEAD: ...
OPTIONS: ...
POST: creating, appending, containment management
PUT: creating, replacing
PATCH: creating, updating
DELETE: remove, containment management

Specifically:

Intention for server-side containment management SHOULD be communicated through POST and DELETE. PUT and PATCH SHOULD NOT effect containment management.

Servers MAY use both the Slug and the Link header values in POST requests to determine hints for containment management. In the following example, the server uses the slashes in Slug as a separator for nested containers based on the interaction model(s) as specified in the Link header.

POST /
Slug: foo/bar/
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

Location: http://example.org/foo/bar/

is equivalent to:

POST /
Slug: foo/
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

Location: http://example.org/foo/

POST /foo/
Slug: bar/
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

Location: http://example.org/foo/bar/



md5-5160ebc88034fe7ab8337c34aadf573e



GET /foo/

Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

<>
  ldp:contains <http://example.org/foo/bar/> .



md5-ecf0c167662d8d06caa5c75a0fbfc919



POST /foo/bar/
Slug: baz
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type"

Location: http://example.org/foo/bar/baz

[dmitrizagidulin]

Intention for server-side containment management SHOULD be communicated through POST and DELETE. PUT and PATCH SHOULD NOT effect containment management.

I think the terminology is slightly confusing. Container management is something _solely_ done by the server, and not a concern for the client (not even communicating an intention). And clients should be able to create/modify/delete resources via the usual verbs - PUT, POST, DELETE.

[csarven]

I think the terminology is slightly confusing. Container management is something solely done by the server, and not a concern for the client (not even communicating an intention).

Taking LDP's "server-managed triples" as given. The attempt was to clarify the affordances of those methods in LDP. Is this more clear:

Clients SHOULD use POST and DELETE to apply LDP's interaction models on resources. Servers SHOULD NOT allow PUT and PATCH to effect server-managed triples.

Re:

not even communicating an intention

I understand the context in which you mean that but I was going with text like the following or other client hints:

LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s)

Clients certainly make their intentions clear to the server. They acknowledge the purpose and effects of using the interaction models eg. POST to a LDPC will result in...

[TallTed]

@csarven - How about --

_Servers SHOULD NOT allow triples within PUT and PATCH payloads to affect server-managed triples._

(Side note: affect, not effect.)

[RubenVerborgh]

We'd need a definition of "server-managed triples" (and maybe a different term).

Also "should not allow" is vague: should they reject it? Or ignore it?

Let's be very specific.

[kjetilk]

We'd need a definition of "server-managed triples" (and maybe a different term).

That's in the LDP spec: https://www.w3.org/TR/ldp/#dfn-ldp-server-managed-triples

[kjetilk]

If I interprete this correctly, the implication of

Servers SHOULD NOT allow PUT and PATCH to effect server-managed triples.

is that orphans are ok, #97 and the system is not strictly hierarchical, #98 .

Thus, I think we need to settle those high-level design issues first.

[csarven]

@TallTed Right! :)

@RubenVerborgh It was partly derived from 5.2.4.1 for the purpose of moving the discussion forward. How about an alternative:

Clients SHOULD use POST and DELETE to apply interaction models on LDPR. Servers SHOULD NOT allow PUT and PATCH to affect LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code.

Note: sticking to only containment triples.

@kjetilk Sure, let's move those forward but not go too high. Use Cases would be the ideal level. I agree that 97 and 98 will help to frame it better.

[dmitrizagidulin]

Ok, while I agree with LDP section 5.2.4.1 "LDP servers should not allow HTTP PUT to update a LDPC’s containment triples", we have a strong disagreement on what the text actually means.

Creating containers via PUT, POST or PATCH does _not_ update their containment triples directly. The updating of containment triples is done solely by the server, as a side effect.

Look, to put it simply, there is absolutely no reason not to allow container creation via PUT. Part of the reason it was brought up as a feature request is because messing with POST + slug for creating containers has historically resulted in a lot fo developer confusion.

[csarven]

Creating containers via PUT, POST or PATCH does not update their containment triples directly. The updating of containment triples is done solely by the server, as a side effect.

Yes, LDP's notion of "server-managed triples" was already covered. Methods are used to issue requests as a whole, including the side effects as mentioned in RFC. A request is not confined to what's in representation body. In LDP's case, it includes server-managed triples and server-specific constraints.

there is absolutely no reason not to allow container creation via PUT.

Okay but that wasn't proposed.

[dmitrizagidulin]

Okay but that wasn't proposed

Ok whew :) All good then