I believe congratulations are in order to Microsoft and Ecma’s TC45 for what appears to be a new world record for creating a standard. Their recently-approved Office Open XML (OOXML) standard weighed in at 6,456 pages yet took only 357 days to be reviewed, edited and approved, making it not only the largest markup specification, but possibly also the fastest to complete its standardization cycle.
To put the magnitude of this accomplishment into perspective, I looked at a variety of other successful standards from various standards bodies, such as:
- OASIS OpenDocument Format (ODF)
- OASIS Darwin Information Typing Architecture (DITA)
- W3C Extensible Stylesheet Language (XSL)
- W3C XHTML
- W3C Scalable Vector Language (SVG)
- W3C Simple Object Access Protocol (SOAP)
- IETF MIME
- Ecma C#
- Ecma C++/CLI
In all cases I looked at how long the specification took to be standardized, from when the initial draft was made available (whether developed within the technical committee, or submitted by a vendor at committee formation) to the time when the standard was approved. So we’re looking at the complete editing/review/approval time, not including the time to author the initial draft. I also looked at the length of the resulting standard.
(Click on the above chart for a larger view)
As you can see, there is a noticeable trend with previous standards, where longer specifications took longer to edit, review and approve than shorter ones. This was the received wisdom, that standardization was a slow process, and this deliberate pace was necessary not only to achieve technical excellence, but also to socialize the specification and build industry consensus.
Also, previous specifications seemed to top out at around 1,000 pages. Larger than that and they tended to be broken into individual sub-standards which were reviewed and approved individually.
The general practice, as shown in this data, has been for standards to take from 0.1 – 1.2 pages per day, for a complete review/edit/approval cycle. Even other Microsoft specifications in Ecma have fit within these parameters, such as C# (1.2 pages/day) and C++/CLI (0.7 pages/day).
Thus the remarkable achievement of Microsoft and Ecma TC45, who not only managed to create a standard an order of magnitude larger than any other markup standard I’ve seen, but at the same time managed to complete the review/edit/approve cycle faster than any other markup standard I’ve seen. They have achieved an unprecedented review/edit/approval rate of 18.3 pages/day, 20-times faster than industry practice, a record which will likely stand unchallenged for the ages.
I think we would all like to know how they did it. High-altitude training? Performance enhancing drugs? Time travel? A pact with the Devil? I believe you will all share with me an earnest plea for them to share the secret of their productivity and efficiency with the world and especially with ISO, who will surely need similar performance enhancements in order for them to review this behemoth of a standard within their “Fast Track” process.
I am optimistic, that once the secret of OOXML’s achievement gets out, the way we make standards will never be the same again.
Change Log
1/26/07 — corrected two typographical errors pointed out by a reader
Given the primarily government (but some industry) demand for standards, we’re probably going to have to come up with some kind of standards body performance comparison or tougher requirements for them to buy in to, so this kind of crap doesn’t accelerate.
Perhaps standards are becoming the “positive” exclusionary tactic to the “negative” tactic of patent pooling. Scary thought.
Hot on the heels: http://blogs.sun.com/dennisding/resource/Open%20Standard%20Definition.pdf
Correct me if I’m wrong, but most if not all of the specs you list were designed by committees with representatives from multiple vendors and covering a wide range of application scenarios. On the other hand, OOXML was essentially a port of an existing data model from a binary format to XML based on the requirements of a single vendor, to cover a single application.
It’s easy to see how a big speed-up is possible if you drop the requirement for consensus between conflicting interests. Problem is you end up with with a spec that’s incompatible with the rest of the world.
You are correct that most of the specifications I listed were hashed out in a consensus committee process.
Is that the sole reason for the difference? I wish I could point to some other similarly-created non-consensus “standard” to demonstrate that it was processed at a similar rate to OOXML. But I’ve been unable to find another example of this. Even other Microsoft submissions to Ecma were done at a more typical rate.
Rob-
Those Microsoft guys are sure A+ students!
Souperman! So that’s what he does when he’s not involved in making documentaries on his experience or saving the world! He speed-reads for Microsoft and ECMA.
Good idea Rob, but I don’t think your numbers are accurate. A lot of the OOXML details come from the formats in Office 2003. That gives them at least 4 years gestation.
Hi Rick,
Similarly, ODF came from OpenOffice roots, and I could tag on several additional years to that. Likewise C# had a parent specification within Microsoft, and SVG had a ancestral work at Adobe, etc. I could add more time to them. In fact most of these standards had some preparatory work done before they were submitted for standardization.
So to compare apples to apples I’m looking at only the time within an standards development organization, since that is the only time one can claim independent review, feedback, multi-vendor participation, etc. I’m looking purely at the time from first draft submission to approval. This includes the review, editing and approval time.
My original thought was: What is the work of a TC when presented with a draft standard from a vendor? What is their task and how long does it typically take?
We’ve both worked on standards. Can you honestly tell me that OOXML is not an unprecedented abnormality?