Normative references and stable documents

(intentionally editing subject).

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.

> Don't reference it, though. That would be damaging to the Web's health.
> >
> > Having the title be the same as the URL standard's would encourage you to
> > reference this stale copy instead of the standard, and thus would itself
> > be damaging to the Web's health.
> ...
> You are *asking* for a fork, either by asking for change of title, or by
> inventing an unacceptable title that forces a document copy.


I personally believe 1) the document should have a title that makes it
clear it is a stable version, 2) all stable versions should be dynamically
updated to point to the most current work in progress as the usual
reference source, but 3) calling these "snapshots" ignores the most
important point - that reaching stability in a spec, or even large portions
of a spec, creates important inflection points in implementation.  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.  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.