Why informal specs usually win

david at megginson.com david at megginson.com
Mon Jan 25 02:10:07 GMT 1999

Paul Prescod writes:
 > david at megginson.com wrote:
 > > 
 > > Informal specs fit into the Worse-is-Better pattern [1]: a less formal
 > > spec that many people can understand easily will generally be adopted
 > > and implemented much more successfully than a more formal spec that
 > > fewer people can understand, despite the disadvantage that the less
 > > formal spec probably contains ambiguities, inconsistencies and
 > > omissions.
 > This is all true, but it isn't complete:
 > formal + hard-to-understand = low adoption, few bugs
 > informal + easy-to-understand = high adoption, many bugs
 > What about:
 > formal + easy-to-understand?

It can be done, but it's an enormous task.  I cannot easily think of a
good example right now, but I might be able to do so if I tried

Certainly, the BNF in the XML spec (which Paul points out later in his
message) makes things generally better rather than worse, especially
given the fact that a primary audience for that spec was parser
writers; on the other hand, I find the BNF in the RDF spec rather more
confusing than otherwise.

 > [...] In other words, formalisms help you to understand *if you
 > know the formalism*. Prose would be easier to understand than BNF
 > for someone who didn't know BNF, at first, but over the long term,
 > it would be harder to follow.

I would have been able to learn how to pronounce the word "Hoosier"
much more quickly if someone had just sent me the IPA (International
Phonetic Alphabet) transcription, because I know IPA; nevertheless,
the explanation "'who's yer', as in 'who's yer mama?'" will reach many
more people.

 > This implies that the responsibility of the W3C is not to avoid
 > formality, but to educate people on a few, well-designed,
 > easy-to-learn formalisms which can serve to increase
 > understanding. In other words, this is one of those
 > short-term/long-term decisions that drive everything.

There are gradations of formality, and I agree with Paul that purely
prose specs are unsuitable both because they are imprecise and because
they tend to be unnecessarily verbose.  I disagree, however, that the
W3C can rely on educating the public to understand a higher degree of
formalisms, if only because people will not accept spending the time
learning the formalisms until they are already interested enough in
the specs.

Or, more succinctly, people won't always bother to learn -- this is
simply an environmental fact in the industry, like the fact the ships
often have to sail on rough seas: figure out where your spec will be
sailing and design it appropriately, rather than trying to change the

All the best,


David Megginson                 david at megginson.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)

More information about the Xml-dev mailing list