Re: Concerns about HTML+ complexity
fox@pt0204.pto.ford.com (Ken Fox)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 15 Jun 1994 22:33:03 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406152019.AA17402@pt0204.pto.ford.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: fox@pt0204.pto.ford.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: fox@pt0204.pto.ford.com (Ken Fox)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Concerns about HTML+ complexity
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text
Content-Type: text
X-Mailer: ELM [version 2.4 PL23]
X-Mailer: ELM [version 2.4 PL23]
I wrote:
> >We really need to think about who in the industry is in the best
> >position to implement/control monolithic standards and monolithic browsers.
> >It isn't CERN, NCSA or the community of Web hackers, that's for sure!
and Chris Lilley replied:
> I would like to see some support for this rather airy dismissal.
>
> >The
> >only people in a position to implement a monolithic browser are those with
> >dedicated (and large) programming staffs --- such as Framemaker or Microsoft.
>
> Again I would like to see a reasoned argument for this contentious statement.
It's surprising that this is the first comment about my article. I was
going to put in more argument on this point but others here thought that it
actually detracted from the other points that I was making. Live and learn
I suppose.
The point I was trying to make is that as software gets more and more
difficult to build (i.e. it's complexity increases) fewer and fewer people
are willing to expend the effort required to build it. There are a number of
examples of really, really good freely available software. Some examples of
these systems are the X Window System, Linux, Net/Free/386-BSD, GNU emacs,
the Andrew User Interface System, Tcl/Tk and TeX/LaTeX. However, these
systems are still the exception --- I think that it's safe to say that it
would be extremely difficult to initiate a project of similar scale.
The situation changes radically as software becomes simpler. If you look at
text editors or small languages the number and variety of free applications
is enormous. Not only are there many implementations of similar ideas,
there are many different ideas. Some of these implementations become
popular and embellished with features --- GNU emacs and Tcl/Tk from the
previous list. Others don't survive but inspire other implementations.
Lot's of "one semester projects" contribute much creativity and fresh
insight.
If I apply this reasoning to HTML+, then there must be some point at which a
browser becomes so complex that very few people are willing (or able?) to
implement one. Obviously we are not yet at that point with HTML. (Looking
at the popularity of Mosaic vs. other browsers though, it seems that HTML is
already hard enough to implement that browsers are not casual undertakings.)
We could probably say that the goal of the current HTML+ specification is to
provide desktop-publishing-like content and presentation to HTML. Certainly
there is very little new hypertext navigation functionality. Web browsers
will start to look an awful lot like desktop-publishing applications. How
many freely available desktop publishing tools do you know? Who dominates
the desktop-publishing market? How easy is it to make a desktop-publishing
application? Who controls the desktop-publishing document format standard?
I hope this adds a little bit of meat to my admittedly airy dismissal.
- Ken
--
Ken Fox, fox@pt0204.pto.ford.com, (313)59-44794
-------------------------------------------------------------------------
Ford Motor Company, Powertrain | "Is this some sort of trick question
CAD/CAM/CAE Process Integration | or what?" -- Calvin
AP Environment Section |