@namedgraph_twitter Putting the repo names / paths aside, the entry document (so to speak) is called "The Solid Ecosystem" (TSE) https://solid.github.io/specification/
here's my two cents...
The aim of the Solid specification is to provide the necessary information for data storage providers and application providers to build in such a way that their users can switch between app providers and data storage providers and take the data generated along without interruption of service.
As for the scope, the scope of Solid is surely as wide open as the Web itself?
which probably has another format
there are lots of normative things
if it's not orthogonal to them, something is not right
@namedgraph_twitter The Solid Ecosystem is more documentation, bringing together orthogonal specifications
@namedgraph_twitter
if it's not orthogonal to them, something is not right
If that were true, then LDP could never have existed, because all LDP does is contrain HTTP to handle RDF. That is, it takes the HTTP spec, prescribes specific usage of certain methods and headers, and mandates Turtle representations for some things.
"something is not right" is not supported by the W3C document you linked to, which states that:
When two specifications are orthogonal…
So there is no requirement for specs to be orthogonal.
In this case, we need to keep in mind that Solid = LDP + WAC + WebID-OIDC (I am grossly simplifying here)
so this is exactly what the Solid spec entry document will say
"to do Solid, use LDP, WAC, and WebID-TLS together in this manner"
the complex truth is something along the lines of
Solid = HTTP + URL + RDF + LDP + WAC + WebID-TLS + WebID-OIDC + CORS + SHACL + Footprints + some more
but is that a "specification" still?
and those specifications will be orthogonal
@namedgraph_twitter It is a specification by all means.
Have a look at solid/specification#13
it doesn't just say "use CORS"
it says "write your server in this very specific manner following this existing spec"
and CORS is just an easy one, where we're more or less saying "just use it", except that it takes multiple paragraphs for something like CORS already
The spec needs to (a) define the protocol and (b) describe the invariant properties of the system when the protocol is followed
It would be helpful to have this conversation in an issue so we can easily refer back to it. solid/specification#29.
However, we are writing a spec document with normative language, and there is a first PR for CORS, which defines it very precisely: solid/specification#13
Should cover your (a), and think also (b) but not fully sure what you mean
@boulderwebdev what will you be using that header for?
Either the browser or nginx is writing over solid-auth-client's Authorization header while I talk to my server (right now I want to hide the server from public view by protecting it with http's basic authentication)