> >Surely specifications can be written to be both easy to 
> understand and precise. No?
> 
> I doubt it.  I tried in earlier revisions of OASIS CVA files 
> and the editors hacked away a lot of the English because it 
> was distracting, imprecise and there were possible 
> interpretations of the English that would have been contradictory.

We (the editors of specs) all try to find the right balance between
readability and unambiguity. Part of the art is knowing what you can take as
read. It's easy to get this wrong. In writing the XPath 1.0 specification,
for example, James Clark didn't think it necessary to state that the sum of
an empty set was zero. This led to a challenge during the development of
XQuery, where at least one person thought that the sum of an empty set
should be an empty set, because that's the closest equivalent to what it is
in SQL; and an argument that this would be backwards incompatible could then
be rebutted by pointing out that the XPath 1.0 specification didn't make any
statement on the matter. James wrote highly readable (and very short) specs,
but there have been many cases discovered where they don't clearly say what
happens in all edge cases.

When readers or reviewers of a specification point out an ambiguity or
omission, the editor has no choice but to fix it. When they point out that
the spec is difficult to read, it's not immediately obvious how to respond.
So the pressure on editors is always to make the language less ambiguous
rather than to make it more readable.

I don't claim that XSD has the balance right - it is, even by the standards
of software specifications, a very tough read. But that's a better fault
than ambiguity or imcompleteness.

Fortunately, if the specification is popular, there are usually people who
will write books and tutorials about it, which are much more accessible to
the average user than the official specification.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay