Chris's Wiki :: blog/tech/WaysToStandards

What I think I understand about how standards get created

October 26, 2009

To condense and stereotype a great deal, there are three general ways of creating standards:

invention, where you come up with something that seems good from more or less scratch (ie, not feeling obliged to pay any attention to existing practice, if there is any).
The risk of this approach is getting your standard adopted in the field; many invented standards fail dismally because no one is interested in implementing them.
The Atom syndication feed format is, I believe, an example of this way.
documentation, where you write down the common core of what already exists and works (more or less) in everybody's implementations.
The risk is that your standard doesn't and can't really solve any new problems; it just helps new entrants into the field and promotes portability.
A fair bit of the original C standard was an example of this.
coordination, where you get all of the important implementors together in a room and find out what they will all agree to do, then write it down.
The major risk is that your standard will probably wind up loaded with compromises in order to get everyone to agree to implement it, and they may not implement it anyways.
(I can't think of an example, alas.)

(Since these are stereotypes, it should not be surprising that real standards are usually a mixture of all of the approaches. For example, the general mythology is that the ANSI C standard documented a lot of things that everyone could agree on, made up others like function prototypes, and got vendors to agree to implement specific semantics for a lot of things that had previously been not well defined.)

Successful standards can and have been created with all three approaches, and I don't think that any particular approach is better than the others. And to a large extent, what approach is best depends a lot on the circumstances in which the standardization is taking place, since each approach protects you against certain vulnerabilities while opening you up to others.

(It's common to laud the documentation approach as the best way to go, but I've come around to not believing this any more; there are situations where it works great, and there are situations where it's pointless, because the real issue is that the existing implementations don't provide the features that people actually need. If you pursue documentation-based standards anyways, you get lovingly written standards and beautifully compliant implementations that no one cares a whit about.)

When discussing standards, it's important to start from an understanding of what sort of standard it is. For example, criticizing a standard for not inventing solutions to new problems when its job was documenting the existing practice is much like criticizing snow for not being warm; it's true but not useful, and it's not going to change any time soon. Worse, such discussions often wind up with people talking past each other, since the sides are starting from completely different basic assumptions (often ones that they don't bother articulating because they strike each side as too obvious to need it).

Comments on this page:

From 78.35.25.18 at 2009-10-26 07:18:59:

Atom was really a combination of all three, and even so, more of the latter two than of the first:

It was very much coordination: the working group consisted overwhelmingly of implementers of RSS and potential implementers of Atom, whose willingness to implement certain things was always a concern. (Entry timestamps were a huge source of contention, f.ex., and the publishers prevailed in batting down a lot of the complexity initially proposed. The consumer implementers prevailed in paring back the complexity of the initial content envelope proposal. There are many examples.)

The WG certainly did feel obliged to pay attention to existing practice, codifying the experiences with RSS 1.0 and 2.0, trying to borrow all the bits that worked, fix the bits that didn’t, and not invent any completely new ideas. (Anyone who wanted to do entirely new stuff was encouraged to design an extension instead.) The result is identical to RSS 2.0 in high-level design philosophy, just with a lot more care in the details. In that sense it was documentation.

It was invention really only in the sense that no existing code already supported the format when the WG came together. But coordination almost always implies that as well, anyway.

—Aristotle Pagaltzis

By cks at 2009-10-26 22:29:55:

I'm taking a strict view of documentation here; it's only documentation if you're just writing down what already exists and what programs already do (the often repeated call for standards committees to just 'codify existing practice'). In theory, if you had a pure documentation based standard, programs would comply with it without needing any changes; the common subset of their behavior is the standard.

(Correspondingly you can create such a standard with only passive vendor involvement; they just have to not change anything that already works. You don't have to get them to actually do anything new. Hence, I think, a great deal of the appeal to both users and vendors of the 'codify existing practices' rallying cry.)

In this view, Atom was still invention instead of documentation; it's just that it was good, well considered invention that based its work on existing practice and experience. As you put it, it borrowed the bits that worked and fixed the bits that didn't.

(Having very briefly written a partial RSS generator, my impression has been that Atom didn't reuse any RSS elements unchanged.)

From 78.35.25.18 at 2009-10-27 06:28:25:

That still leaves the question of what criterion you’d use to distinguish coordination standards from invention standards, though. Coordination necessarily implies either invention or documentation (most of the time, the former).

Basically, I’m thinking that outside of pure documentation standards, in reality, they are always developed under some mix of these goals, albeit with varying emphases.

—Aristotle Pagaltzis

By cks at 2009-10-27 11:57:07:

I agree that real standards are generally a mixture of the approaches.

To me, the distinction between the invention approach and the coordination approach is how much vendor involvement there is. The coordination approach is like the documentation approach in a way, except that your standard is what the vendors will agree to implement instead of just what they already do implement. The invention approach is less focused on getting vendor agreement beforehand.

From 121.45.74.164 at 2009-12-18 06:46:27:

Would you agree that the OXML "standard" is an example of coordination? I'm particularly thinking of when Microsoft entered the discussion and started to throw some weight around to get things changed to suit itself; the result being a sub-standard compromise for everyone.

Nick C.

By cks at 2009-12-18 15:00:59:

In my taxonomy here, I'd put it this way:

As originally conceived by Microsoft, OXML was a pure documentation standard; the ISO would rubber-stamp what Microsoft was doing. As actually standardized, OXML is an invention standard, although it only involves a little invention; in the process of doing minor fix-ups, the standards bodies made changes that obviously had no existing implementation, and they did not get Microsoft's agreement first.

(Predictably, the result was a failure.)

Written on 26 October 2009.

«	Some thoughts on a 'modern' university email system

A personal experience of web browsers making bad text editors