OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] The Browser Wars are Dead! Long Live the Browser Wa rs!

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


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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS