Alternatives to the W3C
Lee Anne Phillips
leeanne at leeanne.com
Fri Jan 21 00:35:51 GMT 2000
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
>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.
More information about the Xml-dev