Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct
@aveltens:matrix.org
The spec says that if there is /public , /public/ can't be created. And, vice-versa. It also says that servers may want to redirect when requesting the non-existing resource (eg. /public ) to the existing one (eg. /public/ ). Now, only after that, it would be possible for client to receive the representation of /public/index.html if the client for example requested Content-Type: text/html for /public/ (after the redirect) , and if server uses Content-Location: index.html in response to /public/ . That's of course this particular server stores the HTML representation of /public/ at /public/index.html and wired up to be served through Content-Location.
Above is certainly possible and would still conform to the spec or at least there are no conflicts. It is not necessarily how every server might behave. Simple case being that server just won't redirect from /public to /public/ to begin with or associate /public/index.html as the HTML representation for /public/ .
If /public/index.html is an HTML representation of /public/ then all write requests targeting /public/index.html must be redirected to /public/ - the spec doesn't allow representations to be updated directly / separately. Updates are routed through the resource URL as opposed to representation URLs.
@timbl We could change "MAY" into non-normative may or just remain silent about it. Redirecting /public to /public/ is a fairly common implementation pattern. Redirect helps people to not trip over slash or no slash diffs or refer to one when the other exists.
Text from the specification:
If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource. Instead, the server MAY respond to requests for the latter URI with a 301 redirect to the former.
Hello,
apologies in advance for a question that is not fun answering.
I am just wondering about a rough estimate on the level of completion of the Solid specifications.
It is for me very difficult by only reading and going over the open issues to make such an assumption. Also, I do not have enough experience developing servers to spot a shortage in specific sections of the specifications, that I could say for example: “The WAC section is too vague for me to implement it correctly”.
I am aware that these specifications are active and conversations are happening all the time about the Solid Ecosystem and that the specifications will probably be worked on for a long time, but I am just trying to get a rough overview of where we are today.
Thank you.
@janschill That's indeed a tough one but I'll give it a shot (and others can shot me down if they like). The short answer is that the key aspects of the ecosystem are for the most "complete". There are some rough edges indeed, some nice to haves or unknowns but that's to be expected. Bear in mind that what makes a spec a spec is not just that there is a nice/readable document to look at but all the work that goes into it, anything from all supporting documents, to publicly demonstrating working implementations based on the specs, as well as actual usage in the wild. There is a lot of iteration on that front. We could call it "ready" at any point but that doesn't serve us or anyone in the end. So, to answer your question more concretely, I would say in 2021Q1, or more realistically Q2 we'll be in a position to wrap up majority of the current work and make a wide call for implementations - not to be confused with the idea that call for implementations/experiences/feedback hasn't been done already or needed on an ongoing basis. To me, the wide call marks a point where we feel the specs are mature enough and expect minimal / hopefully non-breaking changes to the specs based on implementation experience. We need to eventually get a lot of input from users - yes, that includes anyone dogfooding the specs to anyone that only needs to get their tasks done. Think along the lines of whether the servers,.. apps being developed have a net positive effect or harming users.. This is why ethical checks on the path to developing the specs are important. We don't want to be in a situation where we think we are ready for wide use - I don't mean just few isolated users or environments, but for the Web.. - and then deal with major privacy, security, ethical implications. We need to work our way up.. scale up. Don't need to have everyone implementing and using at the same time either. It can happen in phases.. gradually, so that gives us time to improve. When people developing servers, apps etc. can look at the specs and get reasonable coverage. We will weed out stuff that no one is using - and put them into the research/homework/experimentation bucket for later.
Various specs are in the works and they are at different maturity. More specs will come forward. There is no fixed "end" date or completion for the Solid specifications. Just as there is no particular end date for standardisation. W3C is still going after all for obvious reasons. The point of the Solid project is to help towards changing the course of the Web. We are learning about what's broken and propose ways to fix things.
2 replies
Folks on the authorization panel might want to check out the discussion about auth from command line apps at https://forum.solidproject.org/t/authorisation-for-a-mobile-app/3692/9
Responded
@base <http://base1> .
<a> <b> <c> .
@base <http://base2> .
<d> <e> <f> .
<g> <h> <i> .turtle CLI
<http://base1/a> <http://base1/b> <http://base1/c> .
<http://base2/d> <http://base2/e> <http://base2/f> .
<http://base2/g> <http://base2/h> <http://base2/i> .