Re: The Final Word On HTML

Peter Flynn <pflynn@curia.ucc.ie> wrote:
|Critics need to understand that the people who cut the code were in the main
|people with no background in the text processing or information management
|fields: their strength was programming in C, so we need to cut them a little
|slack until they can get to grips with SGML.

Yeah, but that was three years and 3 billion dollars ago.  The major players
have had enough time (and indeed at least one of them has been making major
rumbling noises purchasing SGML talent) to Do It Right.

Marketing has driven development to differentiate products instead of creating
an environment where users can encode their data so that it can live to be
repurposed.  Encouraging HTML to grow by accretion is NO solution--its hard
enough to wade through the cruft as it is.

The best discussion on this topic came out of the now-defunct IETF HTML Working
Group at this time last year and is available at:

<URL:http://www.acl.lanl.gov/HTML_WG/html-wg-95q4.messages/0015.html>

HTML Evolution Considered Harmful - And a Path Out
Version: 1.0
Brian Behlendorf, brian@organic.com
1 October 1995

ABSTRACT

The prevelant concept amongst world wide web application developers and users
is that to introduce new functionality to WWW pages, new HTML tags must be
created. Some proposed and implemented tags have succeeded, others have
failed - most tags were introduced piecemeal rather than as a part of a
cohesive upgrade because radical departures are discouraged by market forces.
It is for this reason that we have the <FONT> tag rather than even a simple
stylesheet implementation. For this reason, development of HTML rarely
follows true "evolution", where good ideas flourish and bad ideas sink.
Instead we are left with "you must be using this browser to view this page",
which defeats the whole purpose of a lingua franca.

The path out of this is to stop evolving HTML into an uberlanguage, and
solidify it into a simple hypertext document language which acts as a
marshaller for arbitrary data types. To a large extent, this is exactly
where it is - transclusion enabled by IMG and EMBED allow HTML "pages" to
really be HTML + GIF's + PDF + anything you want.

What I propose is that the large pieces of separable functionality which
are on the "queue" for being integrated into HTML be taken off the queue
and established as their own data types, whose evolution can proceed
*independently* of HTML. All that HTML needs to be is a simple
structural document language, powerful enough for most applications,
with a solid transclusion capability and the capability to "marshall"
that transclusion.


--

Received on Thursday, 26 September 1996 17:31:01 UTC