If all browsers supported SGML, or a reasonable subset thereof, and
they supported named stylesheets, then this entire issue becomes a
non-issue because all browsers could support all versions of HTML, and
for that matter, even tailor made DTD's for a specific application.
Now everyone will scream "What??! Put and *SGML* parser into our
clients, don't be ridiculous!!" and I will point out that libwww
already goes about 1/3 of the way of supporting enough SGML to make
this possible. It is not *that* hard if one does not use things like
CONCUR, SUBDOC, etc.
What we really, really need is:
1) A "text/sgml" type that allows one to send the information, the
stylesheet, and the DTD.
2) A stylesheet definition language (DSSSL? I don't know anything
about it).
3) A parser in every client.
and we will not have any more wars, and a great deal of freedom.
This *is* the way things will go, I can guarantee that, because
many places with large document databases are already turning to SGML,
and the trend is accellerating. As the trend accellerates, more demand
for SGML support *will* appear, and down converting, while in many
ways useful, will not suffice. We should start working on this *now*
Now, we don't have these facilities here now, so I'll tell you how I
solved this problem in DynaWeb(tm). DynaWeb(tm) does on the fly
conversion from SGML to HTML (or to be precise, from "books" created
by DynaText(tm)). The conversion process is controlled by stylesheets,
and one can name stylesheets in a manner similar to forms:
http://foobar/collection/book?fulltext=name&toc=name
using these stylesheets, one can hide parts of the document, change
formatting, include of hide graphics, create a TOC of figures, etc.
The biggest limitation is that HTML is not designed to be a formatting
langauge.... and I will vehemently argue that it should not be.
In effect, in the above, I am faking what should be in the clients.
I will say no more about SGML support in clients, except to say "wait
a year or two" .