This strategy is used on the server-side in large scale already --
see http://www.novell.com/ 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 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).
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.