Why informal specs usually win

Simon St.Laurent simonstl at simonstl.com
Mon Jan 25 14:34:29 GMT 1999

David Megginson wrote:
>>[Paul Prescod]
>> 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

We attempted this in XSchema; while I can't claim that we did a perfect
job, making the spec readable for the largest possible number of readers,
from implementors to schema writers, was definitely a key goal.  (In large
part this was due to the strong reactions I still get when trying to tease
out meaning from many parts of the XML 1.0 spec.)  The formality is there
in the DTD version of the spec; the easy-to-understand is there in the
prose and example.

Another good case of a highly readable spec is Cascading Style Sheets,
Levels 1 and 2.  (Especially 2.)  CSS is the only recommendation I feel
comfortable telling users to read directly, rather than finding a
translation in a bookstore. (Yes, I know implementors have grumbled about
CSS - but most of the grumbling really does feel like political cover for a
job they did poorly in the first place.)

At 02:56 AM 1/25/99 -0600, Paul Prescod wrote:
>I'm sure it will annoy some people to hear it, but specs are for
>implementors and very sophisticated users. Joe Average will never read a
>spec., no matter how "friendly" it is. Specifications are more like laws
>than they are like novels. The move to informal specs has not decreased
>the need for "language lawyers" -- it has just made their job harder. It
>has also made implementors jobs harder, which works AGAINST the popularity
>of the language.

There is no need to limit your audience to implementors and very
sophisticated users; if necessary, just provide both the formal and the
informal versions, with the formal always having greater priority.  Groups
that aren't willing to write a friendly version are limiting their audience
and demonstrating vividly their lack of interest in real users.  (Among
other things, it makes it extremely easy for their detractors to paint them
as out-of-touch academics - and have people believe them.)

Treating 'real users' as second-class citizens is a common habit in the
computing community, and one that's done real damage to the widespread use
of all of these great ideas.

>[David Megginson wrote:]
>> 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
>> weather.
>[Paul Prescod]
>It is demonstrably the case that the "weather" can be changed. John Backus
>and Peter Naur chose to invent BNF. In doing so they fundamentally changed
>the standardization "climate." Thank God they didn't rely on prose and
>wait for someone else to figure out the formalism later.

On this one I'll agree, though I'm very glad that the growth of XML
promises to eliminate the use of BNF in document formats.  XML, even with
its odd syntax for describing document structures and (still) limited
vocabulary, has more readability than BNF while still retaining a clean and
formal means of expression.

Simon St.Laurent
XML: A Primer / Building XML Applications (March)
Sharing Bandwidth / Cookies

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