Daniel W. Connolly (
Tue, 03 Oct 1995 16:27:52 -0400

In message <>, "Brooke Smith" writes:
>The idea is that documents sent over the web don't necessarily have to
>conform to some DTD, such as the HTML one, but instead the DTD and an
>associated translating program could be sent along with it and the SGML
>parser would render the document according to the DTD and translator. I
>would guess that there would be common formats such as HTML X so that
>only when that common format is updated does a new DTD and program
>need to be sent.

This strategy is used on the server-side in large scale already --
see for megabytes of data managed as SGML
and spit out as HTML over the wire.

>I think this is an idea to play with and wonder why it hasn't been
>discussed before - maybe it has and there is a reason to stick to static
>html documents.

HTML is an "80% solution." It works for lots of things. But the web
architecture is extensible to accept other data formats as need be --
from SGML document types to postscript to Microsoft's avi.

>I would like feedback on this idea since I know this would make the
>creation of customised documents that much easier and I will probably
>persue the idea after my thesis has been submitted (but would like to
>talk about the idea in the thesis).

More info:
I maintain this collection of SGML resources. The thesis is:

SGML and the Web

Our investment in SGML to support HTML should be taken one or two
steps further and leveraged to support other SGML applications. Much
of the world's information is managed as SGML, and more and more of it
is assuming this form every day.

The resources consumed and the information lost by converting all this
data to HTML is much more costly than enhancing Web user agents to
adapt to new SGML document types at runtime, perhaps by using
DSSSL-based stylesheets and/or HyTime-based linking idioms.
NCSA's "SGML and the Web" demonstrates large-scale usage
of SGML on the web, including SoftQuad's panorama browser.