- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Wed, 02 Jul 2014 09:11:09 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Glenn Adams <glenn@skynav.com>, Boris Zbarsky <bzbarsky@mit.edu>, WebApps WG <public-webapps@w3.org>
On Jun 26, 2014, at 9:18 AM, Ian Hickson <ian@hixie.ch> wrote: > On Wed, 25 Jun 2014, Glenn Adams wrote: >> On Tue, Jun 24, 2014 at 8:28 PM, Ian Hickson <ian@hixie.ch> wrote: >>> >>> Compraing implementations to anything but the very latest draft is not >>> only a waste of time, it's actively harmful to interoperability. At no >>> point should any implementor even remotely consider making a change >>> from implementing what is currently specified to what was previously >>> specified, that would literally be going backwards. >> >> That sounds reasonable, but its not always true (an exception to every >> rule, eh). For example, in order to ship a device that must satisfy >> compliance testing to be certified, e.g., to be granted a branding >> label, to satisfy a government mandate, etc., it may be necessary to >> implement and ship support for an earlier version. > > For pointless certification purposes, you can use any random revision of > the spec -- just say what the revision number is and use that (and > honestly, who cares how well you implement that version -- it's not like > the testing process is going to be thorough). Don't ship that, though. Snapshotting a specification is valuable for implementors as well. If I refer to a living standard page, then fragment ID or terminology used in the specification may change in 5-10 years, and I would have no idea what kind of specification the person committed a given code change was following. It's also valuable to ensure the self consistency of such a snapshot since editors often "refactor" specifications to better structure, etc... but that tends to introduce dangling definitions or references and other inconsistencies in them. I do agree that the current long process/practice to move a specification to REC is harmful. We should streamline it as much as possible. - R. Niwa
Received on Wednesday, 2 July 2014 16:11:46 UTC