Why do we write standards?

Hunter, David dhunter at Mobility.com
Tue Nov 9 16:55:47 GMT 1999


From: David Megginson [mailto:david at megginson.com]
Sent: Monday, November 08, 1999 3:01 AM

> 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.

On the other hand, if we look at the whole picture, we're not looking at *a*
standard - we're looking at a *group* of related standards, which all
contribute to one "overall vision" - XML, [XHTML,] Namespaces, Schema,
XPath, XSL, XLink/XPointer, and a plethora of other standards we're all
aware of.  Obviously nobody is saying that if you write an application that
uses XML you have to implement *all* of these standards.  Just the ones you
need.  So I don't think the cost of implementing more than you need is too
great.

> 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.

Standardizing the grammar of XHTML isn't the hard part, imHo, because we've
already been doing it for years with HTML.  All the XHTML people have to do,
in this regard, is say "here is what we've learned from HTML, let's XML-ize
it, and standardize it, so that any XHTML document can be shown in any
XHTML-compliant browser."  (I know, I know, I say "ALL they have to do" as
if it's easy...)  This isn't standardization in advance of implementation,
this is standardization in retrospective.

The *new* part is somehow managing to combine XHTML documents with other XML
documents.  This is the part that could be considered standardization in
advance of implementation.  So if people say <overstatement?>"let's just say
the XHTML namespace is 'blah', do what you want with the grammar and we'll
standardize it later [maybe]"</overstatement?>, that seems completely
backwards to me.  And actually starts us off worse than when HTML was first
developed.  At least then there was some kind of a spec, and the browser
writers just did whatever they felt like with it; but now we're not even
giving them a spec(!).  Just "Okay, do whatever you want, cowboys!"  So
what's going to happen?  Anything a browser writer puts into the browser
that doesn't make it into the eventual XHTML spec will have to *stay* in
that browser, in case there are documents out there that use that feature.
Which is exactly what goes on today.  In a few years time, I don't want to
have to be thinking things like "Okay, if I use this tag I'll have to hack
around this other feature, because the version 8 browser implemented this
differently..."

David Hunter
david.hunter at mobileq.com
http://www.MobileQ.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