Re: Dealing with levels in specs

Hi all,

Thanks Tobie for starting the thread of that topic. Levels on /TR have
indeed started to cause of a lot of problems because so far, we
don't have a good way to manage the different versions of a
specification.
After discussing with different people, we came up with a document
listing 3 proposals aiming at normalizing the latest version links. It
is available at:
https://w3c.github.io/tr-links/versioning/

The idea is to introduce new links to help the different
audiences (browser implementors, web developers, etc) find the
version of the specification they are looking for.

Please take a look at the document and I encourage you to create
issues on the Github repository [1] if you have any questions/comments.
FYI, I created an issue for each proposal [2][3][4]. Feel free to
comment on it and/or +1 on your preferred proposal.

Thank you,

Denis

[1] https://github.com/w3c/tr-links
[2] https://github.com/w3c/tr-links/issues/1
[3] https://github.com/w3c/tr-links/issues/2
[4] https://github.com/w3c/tr-links/issues/3

On 11/16/2016 12:45 PM, Tobie Langel wrote:
> Hi all,
> 
> There's a growing trend in specs right now to start releasing different
> levels of a same spec. It seems it's mainly done to comply with Rec
> track requirements without slowing down editing too much.
> 
> I'd have plenty to say on the irony of editing different spec levels for
> evergreen browsers. And I still don't understand why we're not taking
> advantage of versioning to fast-track spec snapshots to secure IPR at
> regular intervals instead (which would avoid sidetracking the whole
> editing process). But I guess that's a conversation for another time.
> 
> So going back to spec levels, it seems there's no structure in place
> within W3C to handle these levels correctly. From my conversations with
> Denis, it seems W3C treats each level as a different independent entity
> and then does some ad-hoc redirecting on /TR/ depending on requests from
> editors or chairs.
> 
> This leads to absurd situations such as that of the Service Workers
> spec. Currently, we'll find:
> 
> An October 11 WD at https://www.w3.org/TR/service-workers-1/ which point
> to a "Service Workers 1" ED at https://w3c.github.io/ServiceWorker/v1/.
> 
> A June 25, 2015 WD on https://www.w3.org/TR/service-workers/ which is
> obviously very much outdated and points to an ED at
> https://slightlyoff.github.io/ServiceWorker/spec/service_worker/ which
> itself redirects to a "Service Workers Nightly" ED at
> https://w3c.github.io/ServiceWorker/ (which according to the editors is
> the one which should be referenced).
> 
> W3C's API (which Specref pulls data from hourly) makes no mention of the
> latter, and thus everyone is incorrectly directed to the former (with
> it's level-1 ED implementors should *not* be tracking).
> 
> I've bumped into similar issues with CSP which I had to manually fix in
> Specref and others before that.
> 
> If W3C wants to go down the leveled-spec road instead of fixing its IPR
> process, it needs to do so in a structured and organized way:
> 
> - Automate where /tr/shortname/ points so there's consistency across
> specs.
> - Document this so all WGs are consistent.
> - Tie all levels together and not consider them as disjoint specs.
> - Make sure the model you implement works with Specref so it can be
> properly integrated.
> - Enforce one ED referenced per shortname (in pubrules). 
> 
> I know Denis has started working on some of this. I'm essentially
> writing this email to suggest this issues get discussed in the open and
> the work to fix it gets prioritized.
> 
> Thanks for your time,
> 
> --tobie 
>

Received on Friday, 16 December 2016 12:06:44 UTC