feat: weakening the requirement on turtle in favor of orthogonality

[jacoscaz]

This PR weakens the current MUST on Turtle, favoring orthogonality, while still explicitly suggesting Turtle for interoperability.

Quoting from #61 (comment) :

After spending a lot of time going through the comments in this thread, the ones in #3 , multiple threads of conversations on the mailing list and half a dozen private conversations with some of you, my preliminary conclusion is that the best way forward is to weaken the current MUST on Turtle into a SHOULD on Turtle. [...]

• The largest consensus that I can see lies with dropping all requirements (as in MUST) on serialization formats, favoring orthogonality. [...]
• The second largest consensus that I can see lies with one MUST on a format if requested via the Accept: header, doesn't really matter which specific format, favoring interoperability. This is also informed by the view that most users and developers will interact with WebID parsing and serialization only indirectly.
• While a breaking change is needed, this is arguably the least breaking change that can be made while still opening up the spec to JSON-LD and, indeed, any other format (clarification: even when used exclusively).
• In addition to point 3., Turtle is arguably the least complex and onerous format to support from a technical standpoint. If a soft requirement (SHOULD) must be made for interoperability, a simpler format increases the chances that implementations will actually stick to such requirement.

Deadline for review is set to four weeks from now, on 2024-03-25.

As always, the fact that a PR exists doesn't automatically imply that it has to be merged at the end of its review period. This is the first attempt at addressing the issue of serialization formats, following countless comments and literal years of debate. Though I honestly believe that it does represent a good compromise (and the only one I could come up with), I'm fully aware that it might fail to gather enough consensus. The only thing I ask is to approach this with an open mind and some self-reflection on which specific hills each of us really wants to die on.

Do not bother reviewing the spec/identity/index.html as that's automatically updated by our current CI setup based on the contents of spec/identity/index.bs. We'll sort this out in a separate issue / PR.

EDIT: here's the links to the rendered files:

• main branch: https://w3c.github.io/WebID/spec/identity/index.html
• this PR: https://htmlpreview.github.io/?https://github.com/jacoscaz/WebID/blob/ci/feat/weaker-requirement-on-turtle/spec/identity/index.html

[TallTed]

Tiny tweak. The rest is liveable.

[jacoscaz]

The rest is liveable

@TallTed I'll take it :)

[webr3]

I can live with this, however a strong preference to no should turtle, or second.preference to should turtle & json-ld.

Concern being that if a simple change from should to must slips in and we're back to square one.

A no should approach would align with the original super and sub spec approach, allowing sub specs of WebID-Turtle for example to say must Turtle.

[jacoscaz]

/chair hat on

@webr3 thank you for reviewing!

I can live with this, however a strong preference to no should turtle, or second.preference to should turtle & json-ld.

Preference noted! Thank you for being willing to compromise, I really, really appreciate that.

Concern being that if a simple change from should to must slips in and we're back to square one.

If this PR were ever to be merged, reverting to a MUST would qualify as a breaking change, meaning the respective PR would be subject to a review period of four weeks (just like this one). Plenty of time for others to notice a slip like that. While I understand where you are coming from, I also think we'd be safe from this specific danger. Nonetheless, concern noted.

A no should approach would align with the original super and sub spec approach, allowing sub specs of WebID-Turtle for example to say must Turtle.

True, though I am afraid it would push things too far against the interoperability concerns that have been raised, concerns that this PR already puts in second place behind orthogonality.

[RubenVerborgh]

The text as written contradicts itself, but that can be fixed with wordsmithing. Specifically, these as written (not as intended) are contradictory:

• [=WebID Profile Documents=] [MUST] be served using RDF serialization formats.
• [=WebID Profile Documents=] [MAY] additionally be served using any other format requested by a consumer via the Accept HTTP header.

I suggest to use a more precise language, which uses sentences with actors as a subject (documents cannot do anything):

The server MUST offer at least one RDF representation for a WebID Profile Document.

The server SHOULD offer Turtle as one of the representations for a WebID Profile Document.

(the MAY does not need to be mentioned with the above phrasing)

That said, a SHOULD is an insufficient basis for machine-to-machine interoperability. I understand that this is the only compromise this CG was able to agree on, yet the truth value of that statement does not negate it being insufficient to achieve that same CG's goals. A later WG could improve upon this as necessary, should usage indicate so.

[jacoscaz]

/chair hat on

I suggest to use a more precise language, which uses sentences with actors as a subject (documents cannot do anything):

Thanks for reviewing @RubenVerborgh ! Good clarifications that bring no practical changes - I will implement them right away.

A later WG could improve upon this as necessary, should usage indicate so.

Yep, agreed. This CG itself could also decide to change things if/when presented with evidence that this approach doesn't work. It depends on how events will line up (temporally) and what this CG will want to do after addressing the remaining issues. To me, at this time, a new "frozen" ED seems a good idea and I would entertain the idea of a formal report.

[jacoscaz]

/chair hat on

Today's the end of the review window - merged!