Re: Writing v1.0 of the Solid specification

I'm supposed to be "away from keyboard" these days..


On May 15, 2019 00:12, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
>
> Dear all, 
>
> The current specification for Solid is located at https://github.com/solid/solid-spec/. 
> There are a couple of issues with this version: 
>
> – It is a loose set of markdown documents, not a single, authoritative looking spec. 
>
> – These documents are out of sync with reality: 
>   – Some features that are described, are purposely not implemented. 
>   – Some features that are purposely implemented, are not described. 
>   – Some features are purposely implemented differently than the spec prescribes. 
>
> – The documents leave ambiguity in many places, 
>    meaning that they are insufficient to implement Solid. 
>
> – Not everything in these documents has gone through a decision process: 
>   – Some features might be undesirable as basic requirements of Solid, 
>      for instance, for computational reasons. 
>   – Some decisions were taken pragmatically some time ago, 
>      but do not necessarily reflect how we want to continue. 

> The reasons above should show that there is a need 
> to arrive at a consistent Solid specification. 
>
>
> My proposal for this is to start a new document for v1.0 
> that follows the W3C specification template, 
> and to use GitHub’s pull request mechanism 
> to add curated sections of content to it. 
>
> As a follow-up on https://github.com/solid/solid-spec/issues/170, 
> I have currently created the repository 
> at https://github.com/solid/specification/commits/gh-pages 
> with a live version at https://solid.github.io/specification/. 
>
> These curated sections would come from the current spec documents, 
> but they would be rewritten to be accurate and unambiguous, 
> and people in the community should be given the opportunity 
> to comment on texts that get into the spec. 
>
> This process will require processes for moving forward: 
> https://github.com/solid/specification/issues/1 
> and likely 2–3 spec editors 
> (in addition to all of the past and current spec authors): 
> https://github.com/solid/specification/issues/2 
>
> I have also proposed this as a discussion topic for the next meeting: 
> https://www.w3.org/community/solid/wiki/Meetings#20190516_1000CEST 
>
> As always, feedback most welcome. 
>
> Best, 
>
> Ruben 


I generally agree with most of this as well as the initiative but I have some concerns that I'd like to air. After all, the CG is mostly here for that.. ie. to continue with the incubation period for the specs, implementations, and so forth.

Some background and feedback:

The "Solid spec" (however we frame it) wasn't intended to be above and beyond documenting a rough understanding and expectations to enabling the Solid ecosystem. So, nothing was written in stone and it only reflected what we arrived at with part implementations.

The spec "proposals" also only reflected early stages of some of the interactions. The intentions were to move it forward on the spec pipeline. In fact, the Linked Data Notifications spec started from there before moving to the W3C Social Web WG.. as an "actual" spec. And as you all know, it has a scope.

AFAIK, this CG itself can't produce a spec as equivalent to a WG's spec. That is not an issue other than semantics and mostly for approval and visibility awarded by W3C. So basically CG can only hand it off to a WG at a later date.

Which brings me to the point about the past proposal specs being relatively atomic in what they aimed at. Besides being able to experiment and throw away what didn't work out.. The reason for this was to potentially move it to a suitable WG that would be and willing to continue with the work. So, it is more likely that small specs will get to see the light of day outside of the CG than a monolithic spec on "Solid". IMHO: I don't see one giant Solid spec being picked up by a WG - this is especially where some of the parts of the current spec is already using other specs.

Aside: whether making sure that a WG picking up is of interest is a separate discussion, but I just wanted to mention this regardless.

I would rather see this CG focus on atomic specs that would likely fit the ecosystem. That means that the " Solid spec" (or whatever we call it) serves as a guideline to identifying what would work in an *evolvable* ecosystem. It would merely refer to actual specs to describe the bigger picture.

I think there are advantages to taking that route partly because of broader adoption of the individual small specs, as well as to not overly specify how the ecosystem should work. I don't think anyone does precisely beyond a vague idea. We need more implementations on various stuff  (actual use cases) before calling it a day. There are way more challenges than we are aware or even have experience to undertake.

So, for example, it'd be super useful if the CG identified and agree to pursue items like, versioning, immutability, encryption, policies, various aspects of access control, and whatever it finds important and missing out there... Rather than specifying "Solid" right off the bat.

On a related note, I'd like to mention the Fedora spec..  https://fcrepo.github.io/fcrepo-specification/ . To keep it short, that is a topdown spec .. And the folks there tried to cover various highly important areas. I think they did a decent job based on their goals. So, if we strived for "Solid spec" here, it wouldn't end up being above and beyond what they've done there. A lot of overlap. It'll be duplicate work relatively speaking.

I'd rather see a bottom up spec'ing in this CG  because we are more likely to find out to what extent the atomic specs 1) work well with each other 2) can be swapped with something else. See AWWW "orthogonality".

Example: as painful it may have been or seen to invest in WebID-OIDC (after WebID-TLS), it was completely possible because WebID (as well as WebID Profile) was a separate thing. So, my point is that the "Solid spec" may end up coupling stuff where it should not.

PS: unfortunately I can't make it to the next (and probably the one after) call. Happy to join at a later date. I have more feedback to give on the "process" of potential editors, format/styles etc.

I can't believe I typed all this on a phone.

-Sarven
http://csarven.ca/#i

Received on Wednesday, 15 May 2019 17:19:15 UTC