[
Lists Home |
Date Index |
Thread Index
]
I wasn't part of the initial web browser design history,
so I'll have to leave that to those who were to confirm or
deny. The Mosaic browser presented to me was an HTML-gencode
browser. MIME types were presented as content types, so
if you are talking about the history of HTTP, you could
well be right, but that notion of a web architecture
seems to be a late breaking one based on the REST papers
of Fielding, and some are contending that is a post-fixed
design. Even Roy alludes to a cleanup of what Berners-Lee
had done to the time Roy and his folks entered the picture.
Again, you'll have to talk to those folks. But I suspect
what you are claiming will come as a surprise to the majority
of web page makers out there. I think you are post-fixing
web architecture and conflating HTTP/REST and web browser
or Mosaic design skipping right over MIME.
As to Word, you are right. That was the shortcoming of
WYSIWYG discovered before the web was a working prototype,
the fixing of the internal equivalent of the gencodes,
the rendering structures it understands. For that reason,
SGML browsers quickly got away from gencoding and into
stylesheet driven systems, all of which the web community
found it had to replicate as they hit the wall with
gencoding. No one I know of from 1986 on did not understand
the need for document types until we got to XML well-formedness.
As to flexibility, yes, but it comes at a cost of efficiency
given a particular application.
A good example is having a language that uses SQL statements
as built in statments of the language instead of building
up pages of quoted strings. (N-tier is sort of a combination
of all of this in which much of the client-side business logic
goes to middle tier objects which the thin client language
then calls as web services. Catalog them with URLs if you
like. I still can't fathom anyone preferring building up
scores of HTML pages with single forms in them over a client
that handles such forms natively.
len
-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]
Sent: Sunday, October 20, 2002 4:30 PM
To: Bullard, Claude L (Len)
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] The Browser Wars are Dead! Long Live the Browser
Wa rs!
Bullard, Claude L (Len) wrote:
> Not exactly. Some frameworks are evolving to
> make using the classic HTML browser (ie, HTML
> as the host language of a universal intergace)
> less necessary. It is much cooler. I also said,
> if we want to use the term "web browser", that
> term becomes less descriptive of a specific
> platform and becomes more a watered down way
> to say, "web aware because it can use the
> operating system web services without using
> a line of HTML".
Len, the Web architecture was always designed to make it easy to switch
HTML out. HTML has been an optional feature since day 1. If you want a
definition of web-browser that you can describe to someone on the
street, a web browser is an application with a URL-bar where you type in
a URL and the interface changes based on the information retreived.
So Word is not a web browser, no matter how HTTP and URL-aware it is,
because it won't do anything useful when you give it a URL that is not
from a very short list of content-types. You can't configure it to "do
the right thing" with an unknown content-type because its job is NOT to
figure out what to do with incoming data (as in a web browser) but
rather its job is to edit documents in a fixed-list of content-types.
So criticizing the web browser for its reliance on HTML is exactly
backwards. The web browser is the application that was designed to
handle every content type and new content types and tasks all of the
time. It is therefore natural that it will eventually (perhaps slowly)
subsume the tasks of applications designed with less flexiblity built-in.
Paul Prescod
|
