- From: Olle Olsson <olleo@sics.se>
- Date: Mon, 13 Oct 2014 12:15:33 +0200
- To: public-w3process@w3.org
- Message-ID: <543BA645.5070201@sics.se>
Interesting discussion, but it could profit from clear policy statements
about where W3C is on the spectrum:
"living standard" < --- > "canonical stable standard"
The WHATWG policy can perhaps be represented by their definition at:
https://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standard.22_mean.3F
where the evolution of specifications is said to be sort of progressing
in tandem with what browser vendors are implementing.
The W3C policy is implicitly specified by how the process document
describes the life-cycle of standards. The objective of work on a
specification is to arrive at a final stable standard specification at a
specified date. Later there might be need to evolve a new improved
version of that thing, also aiming at a final stable specification.
There is definitely some kind of rationale for how WHATWG chooses to
work, not the least because it was itself a browser vendor initiative
(created by a very small number of browser vendors). And we do see some
rapid evolution in the web technology space, at least if we look at what
is built upon the foundation of what the new HTML will provide.
A challenge for W3C is that the defined process should not only cover
the "HTML family" of technologies (in a broad sense, rapidly evolving),
but also technologies that are evolving at a slower speed. So what W3C
approach to handling specification evolution can be optimal for *all*
kinds of web technology specifications?
We have also encountered the "forking" problem. Is W3C forking WHATWG
specifications? Well, yes, if HTML5 is regarded as a fork of the WHATWG
HTML "living standard" specification. But similarly, when W3C standards
are elevated to ISO standards, we could also see that as a fork, this
time a fork handled by an organization (ISO) that is "slow" compared to
the originating originating organization (W3C). Is this good, or it it bad?
Are we trying to find fixes to the discrepancies between the WHATWG way
of working, and the W3C process? Is the objective to make the gap
between WHATWG and W3C smaller? Or is it to make value-adding
improvements to the W3C process, good for all specification development
work, even if this does not make any difference to the current
ideological debate between the two organizations?
The flame wars seen on the mailing lists during the last month are
incomprehensible to the world at large (who are actually depending on
web technology constructed on the basis of widely supported
specifications).
Let us hope that we leave the flame wars behind, and see more
constructive proposals for improved ways of working, but it would be
good if these are based on a clear W3C policy and "living standards vs
stable standards".
/olle
On 2014-10-09 21:02, Michael Champion (MS OPEN TECH) wrote:
>
> It would be great to start harvesting from this set of threads some
> concrete suggestions for changing the formal W3C process and informal
> practices to address some of acknowledged problems. Just to start
> things off:
>
> 1.Errata - Chairs and the team should more strongly encourage WGs to
> identify outright errors and fix them quickly, ideally inline in the
> published document but at least in an errata document. Jeff’s blog
> <http://www.w3.org/blog/2014/10/decision-by-consensus-or-by-informed-editor-which-is-better/>
> acknowledges that W3C can learn from WHATWG on this, and we need to
> make it happen.
>
> 2.Published drafts of W3C specs should have sections annotated with
> information about how stable, widely accepted, widely implemented,
> and proven in practice the feature as defined in the spec is. It
> might be a good idea to flesh that list/taxonomy out and make some
> concrete suggestions for the process or practice.
>
> 3.We could revisit the very thorny question of how to ensure that
> owners of specs and products that depend on a W3C spec actually review
> changes early in the process before changes are set in stone. Hixie’s
> proposal that specs and dependencies be changed in lockstep is
> interesting but could not possibly scale up to include all
> stakeholders at Web scale. And as Daniel Glazman has pointed out, this
> simply doesn’t work for many enterprises who want to control the
> rhythm of their own infrastructure and app updates themselves. But
> I’m sure we can do better than we do now.
>
> 4.Jeff’s blog mentioned that Community Groups – which do not require
> broad consensus to proceed, but do not produce “standards” – are a way
> to develop specs more quickly. Indeed, the whole point of the blog was
> to muse on the right balance between strong editors (that some CGs
> have) driving “lazy consensus”
> <http://openoffice.apache.org/docs/governance/lazyConsensus.html> (to
> adopt the Apache term) and traditional W3C “broad consensus.” Should
> we discuss how CGs and WGs fit together in the W3C culture and
> process, continue to let them evolve independently from the process
> doc and team’s oversight, more strongly encourage specs to be
> incubated in CGs before a WG is chartered to standardize them, or what?
>
> I don’t think this is an exhaustive list, just a few that seem to come
> up over and over in the WHATWG / W3C meta-thread.
>
> *From:*Chris Wilson [mailto:cwilso@google.com]
> *Sent:* Thursday, October 9, 2014 10:55 AM
> *To:* Ian Hickson
> *Cc:* David (Standards) Singer; Tim Berners-Lee; public-w3process
> *Subject:* Re: Normative references and stable documents
>
> On Mon, Oct 6, 2014 at 7:10 PM, Ian Hickson <ian@hixie.ch
> <mailto: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.
>
--
------------------------------------------------------------------
Olle Olsson olleo@sics.se Tel: +46 8 633 15 19 Fax: +46 8 751 72 30
[Svenska W3C-kontoret: olleo@w3.org]
SICS [Swedish Institute of Computer Science]
Box 1263
SE - 164 29 Kista
Sweden
------------------------------------------------------------------
Received on Monday, 13 October 2014 10:16:05 UTC