XML Standardization Organizations and Processes

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

Mike Champion

Comments (5)
  1. Len Bullard says:

    We’ve covered this ground.  Specifications are for technologies to be fielded and they follow an eccentric orbit until they approach commodity status, a lagrange point among the various forces that determine the evolution of the technology.   At that point, switching costs plunge and the small differences among product design, implementation, marketing and support determine the lifecycle of a given instance.  At that point, anyone still in the market is protecting the resources for the resources: think talent, production advantages, inter-customer relationships for deals of significant size, inter-vendor deals to share market opportunities and so on.

    It is true that the experience of the team producing the specification determines the probable success of a specification.   A standard can be and should be created as a result of a transparent and predictable process.   While the W3C could avail itself of the work of the previous generation, the success rate for its specifications was high.  Now, they have to work for it and they face the same issues as the product vendor and the standards organizations that preceded them:  dearth of talent, the problem of focusing resources, and the need to work within the legacy of previous work.

    Not news.  It will be interesting to see if the emerging second generation web systems producers will learn as much or more or less from the first generation as that generation did or did not from their 40-somethings.  

    All companies and organizations have to cope with the transition from the founders through their gophers to the leadership of a true next generation.   In such transitions, fortunes and careers are made and lost.   And so it goes.

  2. Weddings says:

    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

Comments are closed.

Skip to main content