Re: Normative references and stable documents

On Mon, 6 Oct 2014, Chris Wilson wrote:
> On Mon, Oct 6, 2014 at 5:06 PM, David (Standards) Singer <singer@apple.com>
> wrote:
> > On Oct 6, 2014, at 14:57 , Ian Hickson <ian@hixie.ch> wrote:
> > >> There are plenty of good reasons to reference a snapshot. For 
> > >> example, if document A says “As defined in section x.y.z of R”, you 
> > >> don’t want to risk the section number changing.
> > >
> > > What kind of document would reasonably say that? If it's a spec, and 
> > > R changes, then you should change your reference.
> 
> 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*.

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.


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


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

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


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

I'm all in favour of having archival versions for spec archeology. That's 
why all 8800+ versions of the contemporary HTML standard are available in 
both Subversion and on github, and why we have precached "blame" files, 
and so on. In practice, annual or even quarterly snapshots are 
insufficient for useful archeological analysis, anyway. You really need 
per-checkin commit messages, etc.


(BTW, I'm not on w3process. If anyone has feedback they'd like me to 
respond to, please cc me, as David and Chris have been doing.)

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