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