W3C home > Mailing lists > Public > public-w3process@w3.org > October 2014

Re: Normative references and stable documents

From: Jeff Jaffe <jeff@w3.org>
Date: Mon, 13 Oct 2014 08:22:13 -0400
Message-ID: <543BC3F5.9040806@w3.org>
To: Olle Olsson <olleo@sics.se>, public-w3process@w3.org

On 10/13/2014 6:15 AM, Olle Olsson wrote:
> 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?

This is part of why I blogged recently both about OpenStand, and where 
agility can be improved [1].

[1] 
http://www.w3.org/blog/2014/10/decision-by-consensus-or-by-informed-editor-which-is-better/

>
> 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 Olssonolleo@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 12:22:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:12 UTC