Re: Normative references and stable documents

On Mon, Oct 6, 2014 at 7:10 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 6 Oct 2014, Chris Wilson wrote:
> > That's an unrealistic expectation of the entire content of the world
> > pivoting around the current spec, rather than the state of the spec when
> > the content was developed.
>
> If it's not realistic to expect all the people referencing the spec to
> update, then *don't change the spec*.
>

Also not realistic.  People have been writing production code on WebRTC for
some time now, despite it being "unstable" in practical terms.  Paving a
long-existing cowpath is one thing.  Building a superhighway on a pathway
you just blazed is another.  This all comes down to "there are different
levels of baked, and more baked must equal more stable and a bigger event
to change."

If it's not realistic to expect one to update one's spec when specs one
> references change, then one should not be writing specs. Writing specs is
> like writing software. The point at which you stop maintaining it is the
> point at which it dies.
>

As a spec editor myself, I'm not worried about editing the spec.  Deploying
browsers, and far more importantly deploying web properties that rely on
those browsers' behaviors at certain points in time, are far harder.


> > reaching stability in a spec, or even large portions of a spec, creates
> > important inflection points in implementation.
>
> It's certainly true that a spec can have layers where one set of features
> are "v1" and another are "v2" -- the HTML spec does this a lot, for
> instance, I even use that terminology internally to track when to add new
> features -- but that has nothing to do with publishing snapshots, and it
> isn't what the W3C is doing anyway.


I disagree that this isn't what the W3C has done in the past.


> "HTML5" mixes long-stable stuff with
> highly immature unimplemented stuff (and has lots of stuff that's been
> fixed for months on the WHATWG side, making it even less "stable" than the
> WHATWG living standard equivalent), for example.
>

Yes, there are a lot of things mixed in to HTML5, some long-stable and some
immature.  I don't think the living standard approach makes that better, I
think it makes it worse.


> > This isn't just a reflection of spec commits; it's spec commits and
> > stability of what's in the document, and without strong stability
> > indicators, it's pointless.
>
> Yeah. The WHATWG HTML spec had explicit markers per-section for a while
> indicating how stable each part was. Now that pretty much everything in
> the spec is stable, I've taken those out in favour of localised warnings
> where things are known to be in flux. But again, this has nothing to do
> with snapshots for patent purposes or the way the W3C is doing them.
>

I'm confused, didn't you just say HTML5 is a mix of long-stable and highly
immature things?


> One could imagine having multiple "views" of the spec, with newer features
> omitted from some. In practice this isn't viable because when you add new
> features you often have to make pretty invasive changes to the core model,
> and so maintaining multiple branches becomes hellish. (I experienced this
> when I was editing both the WHATWG and W3C versions of the specs.)
>

Yes, which is why I think stable versioning, with side specs for separable
longer-term efforts and integration when the features are stabilizing and
getting deployed across browsers, is the right way to go.  Similar, say, to
Chrome's release staging.  :)

> Sooner or later, we'll reach a stable "v1" inflection point around Web
> > Audio, and I'd expect implementers to use that as a bar - but additional
> > features will be added, and changes will be made, and of course I'd want
> > implementers (and developers, for that matter) in the future looking at
> > that most of the time.
>
> Why "most"? When would you ever want them implementing or using the old,
> now known-to-be-wrong, stuff?
>

When the new feature set is not stable, or if that new feature set is not
implemented across browsers, or when changes to old behavior is not
implemented and deployed across browsers.