- From: Jeff Jaffe <jeff@w3.org>
- Date: Wed, 28 Dec 2011 02:40:56 -0500
- To: Charles McCathieNevile <chaals@opera.com>
- CC: "public-w3process@w3.org" <public-w3process@w3.org>
fwiw, here's my view. Core technologies areas like HTML and CSS will clearly continue to evolve for a long time. In that sense HTML and CSS are "living". Specifically, within each technology area there are always new component technologies that are being introduced. One example is the video component technology being introduced into HTML in "HTML5". Each time that one (or several) key technology areas are introduced the technologies undergo a relatively similar life cycle. At first there is rapid innovation and experimentation in how to implement the technology. In this highly innovative portion of the cycle - the new technology itself is living. It would typically be a mistake to standardize the technology too early, people will learn better ways, nuances, or aspects of the technology. However, sooner or later, the major elements of the new technology reach a level of stability, and at that point standardization can proceed. Actually, at that point standardization is essential. Whereas in the early stage of the lifecycle the technology is used by early adopters who want to experiment and are willing to invest in a "risky" new technology; once the technology reaches a level of stability, standardization allows the entire ecosystem to make massive investments in the technology knowing that the way it will be implemented is now standard. Although the technology is now "standard", its broader technology area will continue to evolve. Hence although HTML 5 reaches REC in 2014, HTML will continue to evolve. There might be small changes, bug fixes, etc. in a version we call HTML 5.1 - or the next version of HTML might have some significant new feature and we would call it HTML 6. For now, let's call it HTML.next. Here is a model for how this work should get done in the future. In the early, pre-standardization phase of experimenting and developing a new technology, Community Groups appear to have the right mechanisms to allow teams to collaborate on the rapid evolution in the technology. When technology has a level of stability, Working Groups focus on ironing out agreements so that the ecosystem can see a standard that it invests in. "Releases" of a standard might overlap. Before HTML 5 reaches "REC", the HTML WG would already start looking for the collection of ideas that are mature enough to start HTML.next. And yes, the overall approach to WGs would be more agile than it is today. In some respects this is like product releases. A company ships a product; quickly provides new technology to leading edge customers in a beta program; and once the product solidifies it reaches GA level. In parallel, the company is developing the next version or release of the program. While this model does not reflect every type of product - notably those that are continually released on 3 month cycles - it is a frequently used model that seems to work in many instances. Jeff On 12/27/2011 11:04 AM, Charles McCathieNevile wrote: > Hi folks, > > In this still fairly small group there are some proponents of the "living > standard" model where documents are never finished. Some people (me, for > example) think that stable Recommendations are a valuable service to the > community. > > We could have a flamewar about why everyone who disagrees with me is > stupid and foolish (for the 17 values of "me" the group currently offers, > although of course *I* am the one who is right in any real flamewar ;) ). > I think that would be a waste of my holidays. But I do suspect a serious > discussion about why we believe what we do could be a useful exercise, > because there seems to be a lot of common ground in things we think > should be improved, and that we each have some perspective and insight > that the others don't - and sharing that would be a constructive thing to > do. > > So here beginneth the thread, and I'll explain in a reply some things > I think are better about the living standards model (obviously, the > current model is far from perfect, and I think there is a bunch of > good thinking behind "living standards" even if I think the conclusion > is wrong) and some things I think are important about the stable > version world. Maybe we end up with something everyone thinks are > improvements - which doesn't mean the discussion is over, but that we > can propose them to W3C in the meantime, and if they really have broad > consensus we can at least make things better before we get to where we > want to be. > > cheers > > Chaals >
Received on Wednesday, 28 December 2011 07:41:09 UTC