[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] re: Why do we write standards?
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|