The content of the postings is owned by the respective author. vbfeeds.com is not responsible for the contents of the postings. This site is automatically generated and cannot be reviewed for abusive content. If you find abusive content on vbfeeds.com, please contact us at firstname.lastname@example.org and we will remove it. Designated trademarks and brands are the property of their respective owners. vbfeeds.com Copyright © 2005 Serge Baranovsky. All rights reserved.
8/17/2006 2:57:09 AM
There's been a lot of unhappiness about the W3C floating around recently, well-summarized by Dare Obasanjo. Most of us involved with XML at Microsoft share a good bit of the general frustration, if not the specific complaints, expressed in these posts. I don't think there's a strong consensus across the various people and teams on what the problems and solutions really are, but I think many would agree with a few points:
- The process really isn't stacked in favor of anybody, including the "multinationals with expense accounts." The process stresses consensus, with numerous opportunities for those whose views are not reflected in the consensus to appeal to Sir Tim to exercise his veto. The range of groups whose interests often must be "aligned with" a spec is very broad. For example, liason with the Semantic Web, accessibility, and internationalization advocates has been a part of every group I've been involved with. Any discussion of alternatives to existing Recommendations gets vigorous dissent from their advocates, e.g. those who believe that URIs and HTTP alone are sufficient to handle all forseeable requirements for identifying and manipulating data on the web. Needless to say, resolving issues to the satisfaction (or at least exhaustion) of all these parties is time consuming at best, futile at worst.
- Attempts at Design By Committee are generally unsatisfactory. While one can point to counter-examples, the "good" committee-driven standards tend to be those based on solid experience (e.g. Atom, which is essentially a cleaned up version of RSS), or get strong design guidance from a single expert (e.g. XSLT 1.0 and 2.0) . My personal hypothesis for why the W3C had so much fairly rapid and long-lasting success in its early years with HTML, XML, and a few other specs is that they were not really design by committee jobs; the committees served more to analyze experience, write it down, and translate it to the Web domain than to do "design". In other words, they exploited the intellectual capital laid down by government, industry, and academic efforts that produced the internet, SGML, etc. After a few years, the job got harder because there were few examples of successful schema languages, query languages, etc. to build on.
- It's important to distinguish between collaborative experimentation and standardization. There's lots of collaboration among competitors going on, e.g. the preliminary work that leads to the WS-* specs that are submitted to various organizations, or the W3C's XGs, or recent efforts to define microformat conventions. But as Yaron Goland puts it so well, "the cruel reality is that real standards come at the end of a technology's innovation period, not the beginning."
- Ultimately, success or failure depends not on the organization or its process, but on whether a spec is adopted as a de facto standard. (My sound bite is "industry standards come from industries, not standards committees"). That's another cruel reality, especially for those who spend years working on specs that do get enshrined as formal standards don't get much adoption. On the other hand, there are specs such as SAX and a couple flavors of RSS that get widely adopted without any formal standing. Go figure.
The problem with de facto standards is that they are generally moving targets. Proprietary ones can be modified by their owners (although the really successful ones such as MS Word's binary format or Adobe PDF tend to be frozen for a variety of non-technical reasons). Non-proprietary ones tend to fork to meet the needs of different sub-communities (RSS .90, .91, 1.0, and 2.0 being the textbook example). Established and recognized standards organizations have an important role to play in determining whether a technology is mature enough to standardize, in providing a venue for formalizing and testing a proto-standard, and for maintaining it as bugs are found and new requirements added. The value of one organization over another for this generally depends more on the informal community of experts, promoters, and supporters that cluster around a particular organization, and less on its formal process or accreditation. Likewise, the organizations themselves evolve as they gain credibility as purveyors of "real standards".
The W3C was once lean and mean, with XML coming in "fast, low, and under the radar" before the formal process was established. It will be interesting to see if the currently agile and innovative folks such as microformats.org follow the same path to [maturity | senescence].
[Update: The W3C itself is currently debating the question of whether to try to make web developers just follow the formal specs or whether to evolve the specs to accomodate the messy reality out there on the web. A lot of discussion was spawned by a post by Ian Hickson ("HTML5" is a relatively new effort to extend and clean up the HTML in actual use today, as opposed to "XHTML" which is the long-standing W3C working group effort to redefine HTML in XML). The suggestion to ignore the content-type that a web author/host is supposed to set properly (but this often does not happen in practice) vs making HTML5 more "sniffable" to determine what type of content is there set off a vigorous debate on the W3C Technical Architecture Group list, since they advocate the opposite. See Hixon's responses, especially this one:
How do you propose to stop vendors from competing with each other by making their user experience better? There is clear historical evidence that vendors will ignore standards when the standards get in the way of the user experience. Making them feel bad about breaking the specs doesn't stop this (believe me, I've tried).
The W3C "Old Guard" response is forcefully stated by Roy Fielding
Standards tell people the right way to do something for everyone concerned. If people choose to do things the wrong way for their own selfish reasons, then they are liable for the result. Standards cannot define irresponsible behavior as the norm and expect the rest of the system to work. Eventually, one of the browser vendors will stop copying every mistake made by the others and let the market decide for itself.
I know it's fun to dive in and take sides, but I find myself standing back and just watching the parade: You need some elephants to clear the way and draw a crowd, but you need clowns with shovels and brooms to come along behind and sweep up the mess .. and then a cop to ticket people for parading without a permit when it's all over. They all depend on one another: nobody will pay the clowns or cops unless there is a good show, but if nobody cleans up, the paying customers will flee and the elephants don't get fed.]