Re: Editing the WebID spec

Please not that CSarven has helpfully put forward 3 PRs to the
repository recently,

 https://github.com/w3c/WebID/pulls

Those are simple and easy to agree with. 

I find it much easier to work on small incremental improvements,
rather than changes that risk putting everything into question. 

The current document has had 10 years of consensus, so it’s really
up to those seeking changes to make their case, and we’d like to make
sure we are moving consensus forward, not putting everything in question.

Henry

> On 27. Feb 2022, at 17:14, Jacopo Scazzosi <jacopo@scazzosi.com> wrote:
> 
> Hi all,
> 
> Although I never intended to originally, discussion in 
> https://lists.w3.org/Archives/Public/public-webid/2022Jan/0146.html has
> brought me to consider trying my hand at editing the WebID spec into the
> next, and hopefully final, version.
> 
> While I might not be the best candidate for the job, it does look like I
> am the only candidate at this point in time; I am happy to give it a try,
> if you'll have me.
> 
> First question: does anyone have anything against my editing the spec?
> 
> As a community, we seem to be converging around something close-ish to
> what I sketched out in 
> https://github.com/w3c/WebID/issues/3#issuecomment-1036034868:
> 
>> It looks to me as if a good tradeoff would be a WebID Core spec that:
>> 
>> 1. explicitly states that profile documents must be available in one or
>>   more RDF serialization formats (EDITED for clarification)
>> 2. has a SHOULD on a couple of suggested formats (best practices), making
>>   turtle one of them for backward compat
>> 3. explicitly suggests a mechanism for linking to extended profile
>>   documents (best practices), so that Solid can use WebID documents to
>>   find a Solid-compatible, read-write document
>> 4. explicitly mentions writability as an orthogonal concern and that
>>   implementations are not required to be read-write
>> 5. explicitly mentions conneg as an orthogonal concern and that
>>   implementations are not required to support it
>> 
>> Of course, the risk with the above is that clients might end up being
>> forced to implement way too many formats for the spec to be considered
>> practical. However, that would be where the best practices come in.
>> Limiting to turtle, RDFa and JSON-LD with a context that makes it
>> parsable as standard JSON should cover most cases without being too
>> onerous to implement. Turtle is easy to parse, RDFa can be extracted
>> without parsing HTML into DOM maintaining a persistent DOM representation
>> and JSON parsing is everywhere. Full JSON-LD parsing would be an entirely
>> different beast, and thus I don't think we should look at it as a best
>> practice.
> 
> Note that I'm not saying that we are all in perfect agreement on the above;
> I myself, for example, have come to prefer data islands over HTML+RDFa and 
> I would prefer the proposed best practice to focus on the former rather
> than the latter. I'm also sure some would prefer leaving the choice of
> JSON-LD context up to implementors. There's still plenty of discussion to be
> had on the finer details.
> 
> However, there seems to be a growing consensus on relaxing the current MUST
> on text/turtle into a SHOULD and on the orthogonality of read-write, conneg
> and on extended profile documents. I think this would be a good starting
> point for me to begin working on a foundational, organic PR that would lay
> the foundations for further, smaller, more focused changes.
> 
> I understand that some of you may be more comfortable with smaller PRs
> right from the start. However, the extent of the changes that we are
> discussing is such that I would personally find it impossible to be even
> remotely effective without an initial revision of the entire document.
> 
> Second question: does anyone have anything against this approach?
> 
> Lastly, the conversation around WebID is happening both on this mailing 
> list and on GitHub. I tend to favor mailing lists but I see some being
> more active on GitHub; I am ok with trying to keep track of both.
> 
> For those of you who are not following the conversation on both this list
> and GitHub and that do not agree on relaxing the MUST on text/turtle into
> a SHOULD, or any of the above, I would like to learn more about the reasons
> behind your disagreement! I kindly ask you to give your feedback (in GitHub
> or via this list) on 
> https://github.com/w3c/WebID/issues/3#issuecomment-1042324477 , which I quote:
> 
>> However, one single mandatory serialization format breaks a number of use
>> cases, from static hosting to most major CMSs. Basically, all cases that
>> require serving a profile document in a human-friendly format without an
>> easy way to enable/configure conneg.
>> 
>> To this day, Wordpress still retains a huge market share as a publishing
>> platform. Adding a data island within a page or template is easy, adding
>> conneg to serve Turtle is a lot harder. [...]
>> 
>> A similar argument can be made for most CMSs, for statically-generated
>> websites, for hosting files on low-power devices and more.
>> 
>> **If not by relaxing the requirement on a specific serialization format,
>> how would you address these use cases?**
> 
> I hope you will allow me to try pushing the spec forward but I understand
> the reservations you might have; I have never editer a spec, after all, and
> I'm relatively new on the scene. I might make mistakes, I might be either
> too pushy or not pushy enough, I might come across in ways I never intended.
> Most importantly, I might bite more than I can chew, considering how long 
> WebID has lingered in the current draft state.
> 
> The only thing I can guarantee is that, if you'll have me, I'll give this
> my best. I am happy to answer any question you might have, publicly or
> privately.
> 
> Best regards,
> Jacopo.
> 
> ---
> 
> Jacopo Scazzosi
> https://jacoscaz.com
> https://treesandrobots.com
> 
> 
> 
>

Received on Sunday, 27 February 2022 16:33:37 UTC