Why do we write standards?

Simon St.Laurent simonstl at simonstl.com
Tue Nov 9 13:39:54 GMT 1999


At 03:01 AM 11/8/99 -0500, David Megginson wrote:
>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.

I'm not opposed to standards development, but I think David is very right
to question the 'rush to standards' that seems to have infected the XML world.

I've written on this previously
(http://www.simonstl.com/articles/doubting.htm) and will be writing on it a
lot more to come, but I'm deeply disturbed by how many people seem to think
that creating standards is the end-all and be-all of XML.

It's not just about 'proprietary' vs. 'open' - in large part, I'm concerned
that there are enormous costs involved where standardization takes place
before the relationships and information involved are actually sorted out
in practice.  Modeling relationships is especially complicated when the
relationships themselves aren't genuinely standardized.  (Indeed, it's easy
to question what portion of these relationships should be standardized.)

XML itself took a brilliant (though somewhat compromised) approach -
defining a minimum set of tools that could be used by the widest range of
users. That foundation - elements and attributes - provides much more
powerful and flexible structures than was readily available before.

We've got the core set.  Why not let users experiment with that basic set
of tools before we try to slap them in straitjackets?  I hear people on
this list insisting on the need for constraints, for fixed structures, for
all that stuff that made sense when computers were (relatively) slow and
stupid and data structures were hard to convert from one form to another.  

I'd love to leave that baggage behind and recognize that we might have
something genuinely new in XML, a flexible toolkit that can break the rules
we've grown accustomed to over the last fifty years of computing. XML can
break new ground between the formal structures computers are best at and
the more natural structures that reflect how people communicate with each
other, not with machines.

It may not seem realistic to the usual gang of IT people, but I'd like to
see this more flexible approach given a chance before we suffocate it with
experts running around developing standards.  Let local organizations
figure out the tactics before larger organizations create strategies that
may or may not work.

Simon St.Laurent
XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.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)





More information about the Xml-dev mailing list