W3C home > Mailing lists > Public > spec-prod@w3.org > October to December 2016

Re: Dealing with levels in specs

From: Liam R. E. Quin <liam@w3.org>
Date: Wed, 16 Nov 2016 13:14:19 -0500
Message-ID: <1479320059.27355.203.camel@w3.org>
To: Tobie Langel <tobie@codespeaks.com>, spec-prod@w3.org
Cc: Denis Ah-Kang <denis@w3.org>, Philippe Le Hegaret <plh@w3.org>, jungkee.song@samsung.com
On Wed, 2016-11-16 at 09:45 +0100, Tobie Langel wrote:
> 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.

Note that in addition to levels there are also editions - e.g. CSS 2.1
2nd edition to correct errata.

In theory there could be a 2nd edition of (say) CSS level 2 text.

> So going back to spec levels, it seems there's no structure in place
> within W3C to handle these levels correctly.

Nor is there consistent use of teminology across Working Groups.

Nor do we have a requirement that Working Groups provide a mechanism to
identify to which levels and editions of which specs they are trying to
conform, making validation and archiving difficult.

> [...]

> If W3C wants to go down the leveled-spec road instead of fixing its
> IPR process

When the method of working is at odds with the IPR legal framework we
have to ask which is broken and how. The way that specs are being
edited, as you rightly point out, has descended into chaos. Part of
that was because new tooling such as respec and github came along that
were so much easier than using CVS and edln :), that people editing
specs rebelled individually.

Probably we need to rein that in a bit.

> - Automate where /tr/shortname/ points so there's consistency across
> specs.

Note, this would need to be done for all the existing specs too, I

> - 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).
so no branches?

You raise good points, I'm glad you've started a discussion here.

Received on Wednesday, 16 November 2016 18:14:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 November 2016 18:14:53 UTC