Re: Concerns about HTML+ complexity

fox@pt0204.pto.ford.com (Ken Fox)
Errors-To: listmaster@www0.cern.ch
Date: Fri, 17 Jun 1994 16:58:33 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406171451.AA21613@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]

Paul L. Kendall writes:

> Unfortunately, without a major player providing a 'standard' 
> implementation for commercial use, it may not be possible to achieve a 
> stable HTML environment.

Ugh.  My point that the current HTML+ proposal is best suited to be
implemented by a "major player" was meant to be a reason for making HTML+
much simpler, more modular and easier to expand.  I thought it was *so*
*obvious* that domination by a "major player" was *bad* that I didn't
clearly explain myself.

> My experience with various commercial 
> enterprises suggests that each one will implement its own 'flavor' 
> which may or may not be compatible with the rest of the known 
> universe.

That's my experience too.

> I again refer to the Unix history. There seem to be as many flavors of 
> Unix as there are major university computing centers.

This is a Good Thing.  Look how far current Unix is from the original...
with the exception of what some commands are named, there isn't a whole lot
of similarity.  Without the tremendous influx of new and creative ideas,
Unix wouldn't have survived.

The historical problem of course was the fact that there were so many
incompatible variants.  This made even easy things hard.  The existence of a
standard operating system API helps solve (not cures) the portability
problems for the well-known segments of operating systems that people use.
It does not prevent anyone from building better implementations or adding
extra features.  I want HTML+ to do a much better job.  :-)  HTML+ can do
this if it standardizes the extension mechanism.  X does a pretty good job
at this --- look how many vendors have added some proprietary doo-dad without
breaking compatibility with X.

> ... development of a singular commercial 'standard' will 
> probably not occur in the academic environment, nor in a dispersed 
> commercial one, but rather because a major corporation implements its 
> own flavor and aggressively markets it. And as is generally known, 
> such a product will usually not be a fully implemented variety of 
> HTML, but a standard subset from which extensions will be developed.

I think that this is accurate.  That's why we need to make sure that HTML+
itself limits the ability of "a major corporation" to produce a non-simple,
non-modular, non-expandable variant of it.

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