Why do we write standards?

[David Megginson]

Paul Prescod <paul at prescod.net> writes:

> My main question isn't about whether XML should be standalone or a
> derivative of SGML. My question is: "Why do you agree with formal
> standards sometimes and then other times say that we should just
> depend on 'common sense'?" My personal opinion is that anywhere
> interoperability is truly required, it should be formally
> specified. I mean the main argument against the infoset (and groves
> before the infoset, and ESIS before groves) was: "Well that's all
> common sense, isn't it?"

That's a fair question.  The short answer is that I disagree with your
opinion -- standardization is a kind of regulation, and deciding when
and how to regulate is a very difficult balancing act between benefits
(the Socialist view) and costs (the Libertarian view).

Here's the long answer:

When you standardize, the benefits that you hope to achieve stem
mainly from the network effect -- lower development costs and greater
interoperability spring immediately to mind.  These benefits are so
powerful (and so tempting) that they often lead people to rush to
standardization.

On the other hand, standardization has many costs, of which the most
obvious are the initial cost of implementing more than you need to
(since standards are necessarily a superset of the needs of any
specific set of users) and the risk of committing to an inappropriate
solution prematurely and squashing real innovation.

If a standard is successful, the network effect can more than
compensate for the negatives, but most standards simply fail and leave
the early implementors out of pocket.  The problem is that,
traditionally, standardization has solved existing problems: everyone
had trains but they could not run on the same rail gauge, or there
were many different phone companies but customers from one could not
call customers from another another, or every public house used a
different sized glass so it wasn't possible to compare prices.

Now that we're trying to standardize in *advance* of implementation,
we run an enormous risk of messing up: our industry simply lacks any
real, large-scale implementation experience to guide the process, so
we're just publishing our own wild speculations and stamping them as
W3C Recommendations or ISO standards or what-have-you.

The solution is to standardize incrementally to minimize the risks,
and to concentrate initially on the areas that will bring the most
benefit for the least effort.

Since we know so little about mixing HTML into other vocabularies
right now, and since we know almost nothing about how XML will be used
in Web clients, I think that it makes sense to start by standardizing
only a little bit.  Let's give people a standard Namespace (and the
name case) and then let them start experimenting -- in a year or two,
if there's enough demand and if we understand the problem space a
little better, we can try standardizing one step further, but even
then there will always be a point beyond which the costs of
standardization outweigh the benefits.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe 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)