Language and aref hooks for other specs

[kjetilk]

After thinking a bit about general editorial issues in the protocol, I think the issue that got most prominent in my mind was that we need more hooks for other specs to reference when they need to. Let me take a concrete example:

In the interop spec, they say e.g.:

1. MUST return 404 if TREE or REGISTRY cannot be successfully dereferenced.

This is actually and additional restriction on the implementations of Solid servers (as the protocol specifies that amongst other things, a 410 may be returned if the resource has previously existed), which shouldn't be done, and shouldn't be necessary to do.

Instead, specs like the interop specs should have terms to point to, something like "return a non-existent resource error if TREE or REGISTRY cannot be successfully dereferenced.", and then, "non-existent resource error" is a term that we should use in the protocol spec to refer to that kind of situation, and then say that it would mean 404 or 410 or whatever. Those terms should also have ids, so that they can link right to them.

This, I hope, will enable other specs to not define anything that has to do with the protocol, and so enable orthogonality.

[csarven]

I agree that non-protocol spec proposals shouldn't specify protocol level stuff - goes against orthogonal-specs.

With some exceptions, I agree that the Protocol spec can include widely used/agreed terminology that's useful for specs that may need to normatively or non-normatively reference them.

For something like "non-existent resource error", I'd prefer to not define that or terms alike all while within the framework of HTTP.

I agree re ids, and ss far as I'm concerned, "anything of significance" in specs should have a URI ( Axioms#Universality2 ) with a machine-readable description that goes beyond plain HTML. Enter RDFa...

[kjetilk]

I agree that non-protocol spec proposals shouldn't specify protocol level stuff - goes against orthogonal-specs.

Yup, good!

With some exceptions, I agree that the Protocol spec can include widely used/agreed terminology that's useful for specs that may need to normatively or non-normatively reference them.

For something like "non-existent resource error", I'd prefer to not define that or terms alike all while within the framework of HTTP.

The problem is that AFAICS, RFC7231 doesn't have terminology that for example encompasses both 404 and 410. We should absolutely reuse terms when they exist, but in chose that example because I don't think it does in that case.

I agree re ids, and ss far as I'm concerned, "anything of significance" in specs should have a URI ( Axioms#Universality2 ) with a machine-readable description that goes beyond plain HTML. Enter RDFa...

:+1:

[csarven]

Right that 7231 doesn't fixate on a term but it does express that in different ways - along the lines of a representation being available (or not) for the effective request URI. I'm just saying that it is okay to use creative license on something like this.

[kjetilk]

Right, but I think the creative license is owned by us, and that we should use it to invent terms where they don't exist that the rest of the Solid ecosystem should, errrr, MUST use :-)