Why do we write standards?

[rev-bob at gotc.com]

Perhaps I'm coming at this from a different angle than you are, but in the current context 
(Web development and standards), I must disagree with just about everything you say 
here.  Specifically:

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

The Web is supposedly all about interoperability and platform independence.  For either 
of these to be possible, we have to have some way to ensure the following:

1. Web authors must be able to develop pages with some expectation that they can be 
read...no matter what UA a given visitor is using.  The number of UAs and platforms is 
already so diverse that "test the page on everything" is impossible for the average author.
2. UA authors must be able to develop UAs with some expectation that they will 
properly interpret Web pages...no matter what site a given user visits.  The number of 
web pages is up in the millions; "test the UA on everything" is flat-out impossible.

By setting a standard, both sides (theoretically) gain a huge advantage, and thus the third 
side of the discussion - Joe Average, who uses a UA to visit pages - sees a benefit right 
along with 'em.  Web authors can code to the standard, UA authors can code to the 
standard, and Joe Average can use a standard-compliant UA to visit standard-compliant 
pages and see them at least roughly as intended.  That's the goal, right?

The problem comes in when we see incomplete standards, incomplete implementations, 
crude authoring hacks, and old UAs.  For a prime example, take what I was working on 
this weekend and some of last week.  Way back in the HTML 3.0 proposal, a tag named 
Q came along, to demarcate inline quotations.  Q got accepted into the 3.2 spec, and 
carried over into 4.0.  Fine and dandy.  From a rendering viewpoint, Q is extremely 
simple to handle except where the CITE attribute is concerned: put quotes around the 
contents, alternating as needed when one Q tag is nested inside another.  Considering 
how long this tag's been in the specs, this should be almost universal by now, right?  
Wrong; the only currently-available browser I can find which handles Q properly is 
Lynx, starting with version 2.6.  Netscape and Microsoft have both utterly ignored this 
part of the specs, making them noncompliant.  (To be fair, the Gecko build I have 
correctly handles Q - but as Gecko is still pre-alpha, I can't really count that.)

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

And here I thought the whole reason for a standards ratification process and a 
Consortium to oversee it was to address exactly those points.  By the time a specification 
gets to the status of a Recommendation, it has been hashed over much more thoroughly 
than most federal laws; we can hardly consider this result a rash, premature conclusion.

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

And now, everyone has a browser but they can't view the same Web pages.  To return 
to that Q concern, I can solve it with some relatively easy server-side logic - but 
compared to Joe Average Author, I'm the exception.  Most authors don't have that tool 
available, and many of those who do aren't willing to expend a great deal of effort in 
tuning the code that closely.  ("Serve a quotation mark entity to everybody except Lynx 
and Gecko users, and serve the Q tags to everybody except old browsers - does that 
work?"  Yeah, that work...too *much* work.)

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

Hey, we've seen the damage done by leaving innovation in the hands of the browser 
authors - the Web still hasn't recovered from that fragmenting, and the current state of 
affairs is at least partly due to people like myself crying out "Enough!"

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

Keep in mind that once a UA is released, it never goes away - and people like me who 
actually want to communicate instead of just writing "k00l pagezzzz" will have to keep 
developing pages to accomodate it.  "Fix it in the next release" may work inside a 
company, but the general public is justifiably sick of it.  Witness the general public's sour 
reaction to Microsoft's "fix it next time out" attitude with Windows....



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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)