Alternatives to the W3C

[Lee Anne Phillips]

At Thursday 1/20/00 03:47 PM -0500, Tyler Baker wrote:
>directly. A lot of people complain about why it has taken so long for 
>Netscape to include
>XSL support, and all I can say to them is "you get what you pay for". One 
>browser or two
>browsers or three browsers or four, it really does not matter because the 
>incentive to
>innovate with web browsers is no more.

"Free" browsers aren't guaranteed to last forever, any more than "free" 
razors or "free" salt pretzels in a bar. They're marketing "giveaways" 
designed to sell products. Given that Microsoft may or may not be here in a 
recognizable form in the fairly near future, it doesn't seem safe to count 
too many chickens based on continuing Microsoft dominance of the browser 
market either. IBM used to *own* the computing world, and it's now quite 
possible to spend months or years as a computer programmer without even 
hearing their name mentioned.

The most recent competitive strategy of giving away browsers was based on 
the fact that they have the potential to eliminate most or all of the 
operating system user interface and sell back ends based on their 
integration with back end products. Both Microsoft and Netscape used to 
charge for their browser products, remember? Netscape was targeting the 
Windows GUI as well as the NT Server market and Microsoft reacted with free 
and then "integrated" browsers built into the OS. There are still browser 
makers selling browsers (e.g. Opera) based on feature sets, even within 
standards and in the face of "free" competition.

Have you looked at the future plans and developments documents at W3C 
lately? There really does seem to be a grand and powerful vision there and 
the various XML-related standards have the potential to supercede *much* of 
the proprietary stuff the browser makers have done in the past and will do 
in the near future. Whether anyone agrees or not, hand-held devices will be 
browsing the Web in great numbers in the near future. XML and related 
standards make that possible. Look at the history of radio, which is almost 
a non-issue nowadays except in portable devices. Not everyone has no life 
away from their 17 inch monitor and really wants to surf the Web like early 
radio listeners spent hours glued to their custom consoles by headphone cords.

Standards don't mean that innovation stops any more than standardizing on 
using SAE (or metric) bolts, four rubber wheels, a gas pedal, and a 
steering wheel as the basis for an automobile means that we're all still 
driving Model T Fords. The Model T was made possible by standardization, 
and quickly surpassed custom-made cars within a few years. That doesn't 
mean that custom car makers are out of business; there are probably more 
custom car makers now than there ever were. But how many people do you know 
who own one?

The problem with browsers has been that heretofore the browser makers have 
been inventing their own nuts and bolts, so the tool kits of every designer 
have had to include tools to deal with all of them at great expense. While 
this is typical of an immature industry, standardization quickly drives 
custom solutions to the edge of the marketplace rather than the center.

If you look at the history of tools, *real* innovations and improvements in 
productivity have followed quickly on standardization. When SAE (and 
metric) nut and bolt sizes were agreed upon, socket sets and air wrenches 
followed because they were newly possible. Before that you had the choice 
of adjustable wrenches or custom wrenches designed for the particular item 
and that was it. A socket was too expensive to build when it only fit one 
nut and an air wrench needs sockets to be practical.

Programming languages have the same history; the first were designed to fit 
one machine and one machine only. The current software industry owes 
everything to standard languages which hide the details of the machine and 
enable the designer to concentrate on function and real innovation, not how 
many registers are available and whether a conditional branch can be made 
within the limits of a near jump.

There are an enormous number of innovations that a browser maker can make 
*within* the parameters of standards processes that can make life easier 
and more fun for users, just like automobile manufacturers compete on the 
basis of style, power, image, economy, and the hundred other tangible and 
intangible benefits that the customer sees in choosing a BMW over a Lexus, 
or a Jeep Cherokee over a Hummer.

But one of the many things a user *doesn't* have to decide is whether their 
local auto mechanic has a wrench that will fit the spark plugs, whether 
they prefer a steering wheel or a tiller, and whether they're able to use 
the highways designed for Fords or Chevrolets.



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/ or CD-ROM/ISBN 981-02-3594-1
Unsubscribe by posting to majordom at ic.ac.uk the message
unsubscribe xml-dev  (or)
unsubscribe xml-dev your-subscribed-email at your-subscribed-address

Please note: New list subscriptions now closed in preparation for transfer to OASIS.