Add constraint discovery for client errors

[csarven]

Issue #44

[dmitrizagidulin]

What's the use case (necessity) for this? :)

[csarven]

I think it would fall under the UC here: https://www.w3.org/TR/ldp-ucr/#dfn-uc1 -- access guidance, https://www.w3.org/TR/ldp-ucr/#dfn-nf1.1

[dmitrizagidulin]

Are authorization policies in a WAC acl file a constraint?

[csarven]

No, this excludes the details of authorization policies from ACL. It'd be more like linking to the constraint that for example says that server does not allow client to update containment triples eg. https://www.w3.org/TR/ldp/#ldpc-put-mbrprops . Or example from the LDN spec: https://www.w3.org/TR/ldn/#test-receiver-post-response-contraints-unmet (discussed in #44 (comment) )

[justinwb]

Assuming that shape validation would fall into this constraint bucket, it might be helpful to use that as a concrete example?

[csarven]

Do you mean to use the URI of a Shape Validation resource as example? Possibly, but I think I prefer to use a URI that will exist for sure as example, like a URI from the spec. That doesn't rule out the possibility to use server-specific constraints possibly with SV. Just thought that it may be more clear.

I'm still interested in documentation that clarifies the differences between solid:shape and ldp:constrainedBy - beyond https://gitter.im/solid/data-interoperability-panel?at=5e398f03f6945f41ef5ad6a6 and what's currently in the draft spec.

Can we come back to the example after this PR? If an example is desired, we can refer to a requirement in the spec along the lines of:

Link: <https://solid.github.io/specification/#http-client>; rel="http://www.w3.org/ns/ldp#constrainedBy"

but actually have a URI for the statement and use that in the example:

A Solid client MUST use the Content-Type HTTP header in PUT, POST and PATCH requests [RFC7231].

[csarven]

It may be worthwhile to distinguish between the abilities that all clients need to fulfil and the abilities that a (particular) client is expected to fulfil for against a particular resource. Both are important. If solid:shape is already advertising the requirement (or thereof), I'm not sure what the added benefit would be to duplicate that target URI for the ldp:constrainedBy relation. So, from that point, I'd lean on well-defined abilities that a client needs to fulfil to create or update. solid:shape is specific to data whereas ldp:constrainedBy can be for anything (including data).

[justinwb]

✅

[csarven]

Changed milestone to ~CR for reasons.. https://gitter.im/solid/specification?at=5f291b1ce3160e46baa2a17b

[kjetilk]

Since you expressed reservations about this @csarven , and it doesn't seem to be a lot of interest, and it is patching an obsolete file, perhaps we should just close this and return to it once the uses have matured?

[csarven]

As said, I'm not opposed to closing the PR or even dropping the feature altogether. However:

Incorporating implementation feedback is part of the review process. We could close the issue on the basis - in addition to the reservations - that there isn't implementation feedback but then again we have merged features into the specification with zero or one (public) implementation... or even with poor reviewsemoji reactions. When people have bandwidth or interest to pick up this topic, both the PR and related issues are waiting for them. IMO, this PR now patching an obsolete file is not important for the decision to keeping the PR open or closing it - it is a trivial revision.

---

I suggest to raise this PR/related issues in chats and add to the editors team meeting agenda.

---

Aside reminder #44 (comment):

The target URI of the constrainedBy can be a URI that is part of the Solid spec defining the constraint. The test suite uses those constraints in which the implementation reports are also based on.

[kjetilk]

Feel free to raise it in chats. I'm not sure we have the bandwidth to process it, that's all, and then the question is to what extent that it is open represent a distraction. I don't know really.

[csarven]

Current status based on meeting with @kjetilk is same as what mentioned in https://gitter.im/solid/specification?at=5f291b1ce3160e46baa2a17b:

"PR reflects the consensus in the issues [however] it is not significant [..] for the [next draft of the] Solid Protocol."

Will revisit.

[csarven]

I've re-re-reviewed this PR and related considerations, and then rewrote it. All things considered, it is appropriate to include this as non-normative content. We can revisit the requirement levels for constraints and problem details when the needs/demand is stronger. Alternatively, and depending on how things progress, content along these lines could move to a Best Practices document.

I'd like to draw some attention to continuing related work on structured error messages in RDF: #28 . Such work will provide specific/granular information to recipients of the message to help them or the users on their next steps.