Add constraint discovery for client errors

[csarven]

Issue https://github.com/solid/specification/issues/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

[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 https://github.com/solid/specification/issues/44#issuecomment-648048614:

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: https://github.com/solid/specification/issues/28 . Such work will provide specific/granular information to recipients of the message to help them or the users on their next steps.