Re: Normative references and stable documents

On Thu, Oct 9, 2014 at 2:09 PM, Ian Hickson <ian@hixie.ch> wrote:

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

Over time, both specs get updated, implementations get updated, and we
continue.  I think whether that change is reflected by checkpointing
forward-point stable specs or having all specs be "living" doesn't change
the end goal.  In this case, independent of anything else, I'd say if the
lowercase version is widespread, then it would be hard to have this be a
new revision of the same 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.
> >
> > 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.
>

I think we disagree mostly on how instantaneously we expect change to
happen, and how tightly held our concept of "stable" should be.


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

Ah, I see.


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

Any mix of long-stable stuff (<img>) with new untested features (srcset) is
likely to cause confusion, unless it is carefully labelled.


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

It sounded like you said "we used to have explicit markers, then I took
them out because pretty much everything in the spec is stable."

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

Noted.  I'll denote these as W3 HTML and WHATWG HTML, then.


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

An interesting subtlety.


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

If the new version was not yet stable, but the feature were highly
interrelated, yeah, I suppose I might prefer they implement the old (but
internally self-consistent) version until the new version were stabilized.
Depends heavily on the implementer's release model, I suppose.  (Shorter
timeframe of releases would lead me to prefer potentially-broken but
soon-to-be-updated new version reliance.)


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


Hey, if we could move everything  - browsers and content/apps - to a fast
and maintained deployment cycle, we would have far less of a problem, I'd
agree.