Re: Concerns about HTML+ complexity

lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
Errors-To: listmaster@www0.cern.ch
Date: Thu, 16 Jun 1994 21:48:35 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <94061620183561@cguv5.cgu.mcc.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
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

Ken Fox wrote:

>But this is not really the same thing.  These projects are (for the most
>part) sponsored and controlled by individual groups --- not some coordinated
>large effort.  It's like saying the contributed software in X is more complex
>than the X server or the Linux kernel.  This is not true.  Indeed, the
>aggregate of all of the contributed X packages is *a lot* of code.  But
>because they are all independent projects with little interaction, the
>complexity is containable.

Containable complexity. Exactly.

>I want to preserve the current Web model of lot's of people developing tools
>in all sorts of places with loose coupling between them.

So do I. I think we agree more than we disagree.

>Chimera is ahead of the game then --- I believe that the emacs browser does
>something similar.  But this is still browser dependent (I can't write one
>external rendering agent and expect it to work against a whole class of
>browsers)

Yet. There is an interface specification in the works, it has been referred to 
occasionally over the last couple of months.

[me]
>> OK then, I will agree with you. But the last thing we want is a monolithic 
>> browser, so that ceases to be a problem.

>Let's not have a monolithic HTML+ standard then...

That is not the same thing at all. It does not follow from what went earlier. 
Please show how going to a distributed model of implementation requires that the 
HTML 3.0 specification be subdivided.

[about the commercial companies muscling in]
>I hate this possible future as much as you do.  Why do you think that this is
>such an unlikely future? 

I don't, thats why it wories me.

>Let's create an interesting browser/rendering
>market where "best of class" tool integration is designed into the
>architecture.

I think that is what I said, too. Yet you seemed to be arguing that only Frame 
or Microsoft should develop Web software. Perhaps this was a straw argument and 
I missed it?

>>Do you see 
>> some huge corporation coming out with statements like that? No. 

>No, but I do see some corporation modifying their desktop-publishing tools so
>that they "do" HTML+.  

So what? If Frame can output HTML 3.0 I am happy (I use Frame 4.0 a lot, BTW). 
So it can output HTML better than WebMaker? Fine, if the price is right I buy 
it. I don't see that being able to convert WP to HTML has any effect on, say, 
someone developping an applet for news posting or whatever.

>Then those become popular, the applet market goes away
>and the Web becomes a boring place to live (for a programmer... :-)

Not so. LaTeX2HTML is popular. Did that prevent Fish search appearing? Did it 
stop Chimera coming out? I fail to follow your argument; these issues seem 
nigh-on orthogonal.

>What a lead-in!  This is exactly one of the things I want to see allowed ---
>you just defined a new tag (on the fly I suppose.)  Why not allow the tag to
>be formally defined in the document header

a) and you were concerned about document complexity (according to the subject). 
Oh well.

b) I believe examples of this markup have been circulated recently on either 
www-talk or www-html. I confess to frequently being unaware of which list I am 
on (blush). I gather you have to declare the thing using some ghastly syntax in 
the doctype bit before <html> tag.

Anyway it seems we are pretty much in agreement. We just differ on how likely it 
is that a browser can be built as a flock of applets and that applets could 
conform to an interface specification and be portable across browsers. To which 
I would say, when Steve Putz hacked out the Xerox map browser I bet he never 
dreamed that CGI would let the same script work on CERN, NCSA and any other 
compatible server. Proof by related example (grin, ducks)

--
Chris Lilley
+-----------------------------------------------------------------------------+
| Technical Author, ITTI Computer Graphics and Visualisation Training Project |
+-----------------------------------------------------------------------------+
| Computer Graphics Unit,        |  Internet: C.C.Lilley@mcc.ac.uk            |
| Manchester Computing Centre,   |     Janet: C.C.Lilley@uk.ac.mcc            |
| Oxford Road,                   |     Voice: +44 61 275 6045                 |
| Manchester, UK.  M13 9PL       |       Fax: +44 61 275 6040                 |
| X400:  /I=c/S=lilley/O=manchester-computing-centre/PRMD=UK.AC/ADMD= /C=GB/  |
|  <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A>   | 
+-----------------------------------------------------------------------------+