The Rush to Standardize
October 18, 2000
It seems that hardly a week goes by without the the formation of another vendor consortium or partnership tasked with standardizing some aspect of our business or technical environment. But there's been a marked increase in standardization efforts over the past few years, largely centered around XML.
XML-DEV has been debating several aspects of the standards process this week. Discussion has covered the relative merits of different standards organizations and the openness of their processes -- a favorite point of debate for XML-DEV.
This week we look at two aspects to this discussion: the merits of rushing to standardize, and the importance of clear technical documentation.
Pace Yourselves
In a pithy comment Joe Kesselman summed up the speed with which XML and its related standards have developed.
Let's face it: If XML was a commercial product, we'd still be in beta-test on many of the things which are now RECs.
There's no disputing that a number of XML technologies have been developed very quickly. Yet XML's fast and low image glosses over the venerable history of markup technologies: SGML has been around for a long time.
Gavin Thomas Nicol observed that this accumulated experience, and the avoidance of vendor pressure, contributed to the success of XML. Continuing, Nicol expressed concern over the pace of the standardization effort, predicting a brief lifespan for many standards.
I think my main complaint is that people are trying to standardize too much too fast...
I'm a fan of "rapid evolutionary design," and feel that until you've solved the same problem a few times, you certainly don't have enough experience to define a standard. I'll be *very* surprised if many of the recent standards don't either fall by the wayside, or change drastically over the next 5 years.
Nicol outlined the main causes for his concern, citing lack of previous experience as detrimental to the quality of the standards being produced.
My main concern with many of the recent "standards," SOAP et al. being among them, is that they are *not* advised by past experience.
I would argue that in a number of cases the standards that are being created are worse than they should be because either:
a) The space of the standard is so poorly understood in general that without experience in implementation to guide practice (as per IETF) no standardization should take place. I put almost all XML messaging proposals into this bucket.
b) The representation on the standards committee is such that the voices of experience are drowned out. I have seen this happen a number of times, and one form is "vendor pressure," where politics play more of a role than technical/market correctness.
Danny Vint noted that the speed with which the XML specification was delivered has created an illusion of fast-paced development, which is hard to realize in practice. Vint acknowledged that XSLT and the DOM are two other technologies which have benefited from previous efforts.
The only other W3C spec that I think fits this XML mold is XSLT that somewhat owes its history to DSSSL and Jade and then James Clark's implementing an XSLT processor as they worked. Everything else in the W3C other than DOM has been bogged down and taking forever. These specifications show the reality of working groups and standards development. It is long, complicated and full of compromises when it is trying to break new ground.
Scalable Vector Graphics (SVG) and SAX are other standards that follow the model of deriving a standard based on previous implementation experience.
David Megginson had little good to say about standards not based on prior art.
Anyone who tries to write a standard that isn't based on a lot of prior art is simply wasting our time -- for standards writers, innovation is a sometimes-necessary evil, but it should never be a goal.
In his typically colorful fashion, Len Bullard had a few words to describe the iteration involved in technology and standards development.
If it is a good and workable idea, it may bob to the surface several times before it gets a lung full of air and starts swimming. The hype surrounding it often is what pushes it to the surface. In the long term, it has to be useful and in most cases, reasonably easy to use.
Defining standard vocabularies is a key component of many industry standards efforts. Bullard stressed the importance of meeting current requirements over the desire to standardize early on, when defining these XML vocabularies.
The network effect happens by consensus. There is no way to force enterprises to consent until they want to.
... When you design a schema, do not try to solve the problems of every conceivable user of the vocabulary: focus on the one who asked you to do it. Scope it to their precise requirements as best as you and they can define them. Spend a lot more time on defining these before you write a line of XML.
Iterative development models are currently in vogue. This seems at odds with the current trend towards standardization, which follows a largely linear path. It's time to explore the adoption of an evolutionary approach in standardization efforts. Although standardization is aimed at achieving interoperability it doesn't preclude change, it merely calls for managed change.
Seek Clarity
Concerning the quality of writing in standards documentation, Joe Kesselman observed that technical writing takes a back seat in the standards process.
Most companies would rather put manpower/mindpower into developing the standard itself -- because they need to make sure it's something they and their customers can live with henceforward -- than into wordsmithing, and it isn't often that you find both strong technical skills and technical-writing skills in the same individual.
... Nobody writes poorly deliberately. Specs are and always will be written for the "experienced practitioner" -- and will tend to be terse as a result -- but there's certainly room to improve communication with that community, who can then explain the implications to the less-experienced folks.
Thomas Passin commented that writing technical documents often improves one's understanding of the key concepts, making it a worthwhile goal.
Terseness can be fine, and writing for the experienced practitioner is too. But have you noticed, when you try to refine and improve the communication of the concepts, it helps you understand or even discover what they really are? Or it may help you find assumptions you didn't realize were there.
Using the XML Schema specification as an example, Eric Bohlman drew a distinction between the requirements of an implementer versus those of a schema author.
The problem is that implementers need a much greater level of nitpicky details than authors do, largely due to the "be liberal in what you accept and conservative in what you send" principle. They need to know exactly how lots of corner cases should be handled, cases that very few authors would actually generate, and that sort of thing requires mind-numbing detail. A spec that avoids the levels of detail that are irrelevant to anyone but implementers, and therefore would be useful to authors, is going to be useless to implementers.
Edward Loh also stressed the importance of precise definition in a specification.
Both comprehensibility and *clarity* of writing are critical because... [a] clear and concise spec minimizes room for individual intepretation by implementers of all kinds. And that, I believe, is one of the fundamental philosophy of XML.
Recognizing that there are two potential groups of users of a specification document, Linda van den Brink suggested that separate documents should be targeted at each.
...[M]aybe it's a good idea to split specifications up in normative docs (target audience: developers who implement the spec), written by the same editors that write the specs today, with review input from tech writers, and informative docs (target audience: users of the standard described in the spec), written by tech authors with the normative document as input.
There was general consensus that improving standards documentation is a worthwhile task, although there was no expectation that this is likely to happen. Who would pay for the work to be done? Hopefully this pessimism isn't justified. Gavin Nicol captured the inherent importance of making standards accessible.
For speed of development and general coherency of a standard, shared understanding and shared goals are invaluable.
Shared understanding is achieved by good documentation of both the standard and the design process that produced it.