W3C home > Mailing lists > Public > public-w3process@w3.org > November 2014

RE: WHATWG/W3C collaboration proposal

From: Domenic Denicola <d@domenic.me>
Date: Tue, 25 Nov 2014 19:04:52 +0000
To: Daniel Appelquist <appelquist@gmail.com>, "public-w3process@w3.org" <public-w3process@w3.org>
Message-ID: <e8868e579b4d4a70b0778ad2f50ebfcb@CY1PR0501MB1369.namprd05.prod.outlook.com>
From: Daniel Appelquist [mailto:appelquist@gmail.com] 

> Only commenting on the above point: there is a (possibly philosophical) difference of opinion on which spec “implementers" can or should be pointing to. I’m wondering if it’s possible to come to a compromise solution that does not require us to resolve this difference of opinion. For example, the snapshot could say “This is a snapshot. Living version is [here]” and point to a “living diff” between the snapshot and the living version (so that anyone can determine just what the most up to date changes are), with some wording about “we recommend implementers reference the living version for the most up to date changes.” … rather than saying “this is not for implementers” or “this is only for IPR purposes.” ?

I disagree with this kind of handwaving as a solution. The spec is authored as a living standard, and the editors believe implementers should consult the living standard. If there is a snapshot created for the purposes of the output of the W3C process (wide review, IPR, etc.) it does not change the editor's recommendation for implementer behavior. The snapshot should be clearly labeled with what its purposes were. (Another reasonable subtitle that captures this would be something like "Snapshot for purposes of the W3C Process"---unsure if that starts bordering on snarky?)

> That way you leave it up to the implementer / developer to decide based on their own needs whether to use the snapshot or the living spec?

Specs have a role in normatively recommending what implementers and authors do. We should not abdicate this role, even if it is politically expedient.

Received on Tuesday, 25 November 2014 19:05:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:13 UTC