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"
that's the simple truth
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"
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)
you could turn off account creation, and have a blank front page, and the rest of the site is protected..
meaning, when I change the
solid-auth-client to git+https://github.com/user/my-solid-auth.git, npm is getting into a tizzy about permissions issues
if before your package.json was “solid-auth-client”: “^2.0.0”
you can switch it to
“solid-auth-client”: “user/my-solid-auth”
and it’ll work
but if you go ahead and clone the repository, delete the
.git folder, create your own repo and set it up in the cloned folder, push it up to your new repo, then running npm i complains about building this repo