OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: Why do we write standards?

[ Lists Home | Date Index | Thread Index ]
  • From: "Hunter, David" <dhunter@Mobility.com>
  • To: XMLDev list <xml-dev@ic.ac.uk>
  • Date: Tue, 9 Nov 1999 11:56:59 -0500

From: David Megginson [mailto:david@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

> 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

David Hunter

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS