Re: Normative references and stable documents

On Thu, 9 Oct 2014, Chris Wilson wrote:
> 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.

I don't understand your point of view here. Maybe you can try to explain 
to me how you think this should work.

Suppose you have two groups, A, and B, writing specifications.

B is developing is a higher-level technology, which depends on A's 
technology.

At some point, A decides that instead of everything being lowercase, it 
shall be uppercase, making a change that breaks compatibility with earlier 
versions. If any code was deployed that implements the lowercase version, 
then it doesn't work with code that implements the uppercase version.

In my worldview, this can only happen if there is in fact a sufficiently 
low volume of code that implements the lowercase stuff that all the code 
can be updated. The B spec gets updated and uses uppercase, all 
implementations of A and B get updated to do uppercase, and we continue.

In your worldview, what happens? B continues to not be updated? B 
references the lowercase version of A? What do implementations do? I don't 
understand. Can you help explain this to me?


> People have been writing production code on WebRTC for some time now, 
> despite it being "unstable" in practical terms.

Whether it's unstable or stable is, IMHO, exclusively a function of 
whether or not production code depends on it that can't be updated. If 
enough code depends on it in a way that it won't work when the spec 
changes, then the spec can't realistically change, and the spec is stable. 
If the code depending in it can change if the spec changes, then you're 
fine, and there's no cowpath or legacy to worry about.


> 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."

Sure. I'm not sure how this affects the argument regarding references 
though.


> > 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.

I don't disagree with what you wrote. What you wrote doesn't seem to 
contradict what I wrote, though, in case that was your intent.


> > > 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.

I'm talking about the specs that the W3C is copying from the WHATWG these 
days. In the case of these specs, they are not doing the make-it-stable- 
then-ship-then-advance thing. I agree that the W3C has done this with some 
other specs (generally, the problem with W3C specs that are entirely 
developed within the W3C stable is that they don't get maintained 
post-REC, not that they are snapshotted arbitarily).


> > "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.

Can you elaborate on this? How does it make it worse? Do you have any 
concrete examples?


> > > 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?

What is confusing about what I wrote?

You said that we should have strong stability indicators in the spec.
I said that we have strong stability indicators in the spec.

(Also note the difference between "HTML5", i.e. the W3C fork which is 
months old relative to the things that have been fixed in the WHATWG 
version, and "HTML", the WHATWG document. Not especially relevant in this 
specific case, but confusing these is likely to lead to miscommunication.)


> > 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.

That's more or less what I've been doing at the WHATWG with HTML for the 
last few years. e.g. look at how <template> was merged in once it was 
developed. This seems orthogonal to the issue at hand, though.


> Similar, say, to Chrome's release staging.  :)

Chrome's model wouldn't work for specs, because you would never want an 
implementation to implement something with a known bug.

It's similar to how Chrome's normal model doesn't work for 0-day security 
bugs. When there's a security bug, all the branches get updated at once, 
so that there's not a multi-week window where people are left vulnerable.


> > > 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.

I think you answered the question for authors, not implementors. When 
would you want implementors to look at the old version? (Presumably you 
don't want implementors to look at the old version when they haven't 
implemented the new one, or they'd never be able to implement the new 
one...)

Are you planning on maintaining both v1 and v2 in parallel? In my 
experience, doing so requires a high level of effort. I'm not aware of any 
W3C or IETF group having ever done that before in a successful way. (e.g. 
the HTML5/5.1 specs in theory are done that way, but the result is that 
most fixes haven't made it to 5, leaving it in a horrible state.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 9 October 2014 21:09:53 UTC