Re: Writing v1.0 of the Solid specification

Sarven makes some excellent points here about a top-down vs. bottom up
specification. Having worked a bit on the Fedora specification, I would
make two comments.

First, there are both pros and cons to a top-down specification (I agree
with Sarven's assessment that Fedora is a top-down spec). From what I have
seen of Fedora, that top-down approach will work suitably well in a clearly
defined, domain-specific context; however, once you are outside the
expectations of that domain, the top-down approach can be overly
prescriptive in ways that are counter-productive. Effectively, conformance
becomes all or nothing.

Second, Fedora itself implements Solid's WebAC specification though it
ignores nearly everything else from Solid. It is able to do this because
WebAC is sufficiently atomic. I see this as a good thing: initially, the
main audience of the Solid spec will likely be people building clients and
servers for the Solid ecosystem, yet looking into the future, there may be
completely different systems that are able to build on relevant subsets of
the Solid specifications in ways that are hard to anticipate. And with a
more atomic structure, those future systems will likely have an easier time
implementing those parts of Solid that make sense for whatever the domain
happens to be.

Aaron



On Wed, 15 May 2019 at 13:19, Sarven Capadisli <info@csarven.ca> wrote:

> 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