Re: Writing v1.0 of the Solid specification

I was curious who Fedora's target audience is, and if there are any
reference implementations?  I'm working on a Solid server, by building out
the LDP spec and wrapping the Solid authentication & ACL mechanisms around
it.  The Fedora spec looks daunting, and I'm curious if it's worth building
that in addition to my LDP implementation.  Does it fit well with Solid's
goals?

This is my first W3 CG, and I only joined two weeks ago, so I don't have
much input on the process of creating the Solid specification(s).  I did
notice a lot of the specification is still in flux (and seem to be
dependent upon what's been built in NSS), so I'm glad the Ruben is taking
the initiative to start locking things down.  I'm happy to help where I can!

Regards,
Mike

On Wed, May 15, 2019 at 4:53 PM Aaron Coburn <acoburn@apache.org> wrote:

> 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
>
>