I’ve been involved in standards work since the late 1970s, and I’ve always viewed the primary objective as interoperability. Interoperability demands unambiguous specifications (as much as humanly possible) and verifiable conformance – preferably machine-verifiable. A standards body creates a spec and defines conformance criteria; people implement that spec and test their implementations for conformance. That’s it. (I like to think in OO terms: a standard is an object with one method, conforms(), which takes an implementation and returns
About a year ago, this came up in a certain web services group: there was a great flurry of activity to try to develop glossary entries for the terms synchronous and asynchronous, even though the terms were not used in the standard. Everybody had their own pet definition, usually in terms of some (irrelevant) implementation behaviour. I tried to apply my usual thinking to the issue, and I got stuck. I generally find that this is a good reason not to act. (Of course such self-restraint is hard for a standards group: like fishes, lack of forward movement usually presages death….)