>I mentioned something like this on comp.infosystems.www a few months ago,
>and was flamed to a crisp because I smelled too much like an SGML true
>believer. I have the impression that, at the very least, I will get some
>constructive criticism from this group.
Well, one would hope so. SGML is coming, one way or another.
>One simple way to do that is for the DTD to map elements to HTML+ elements,
[...]
>It would be better to have both HTML+ and the new DTD define their
>default presentation in terms of an underlying architecture, using
>fixed attributes.
[ Glenn then goes on to outline a rather interesting technique ]
Two things strike me as interesting here: The first is that you are
essentially saying that the formatting for both HTML+ and other DTD's
be specified in some underlying architecture. This is a good idea
(because it buys some generality at little cost), but we don't have
the underlying architecture (yet). Perhaps the other discussions about
a high-level X11 might have bearing here.
The second thing I find interesting is that you use fixed attributes
within the DTD. In some ways, this is good, but in general, I would
argue that any parser that can support SGML to that level, would also
be able to support stylesheets as well. The stylesheet architecture I
imagine would just simply be a mapping table, say for example, mapping
a <CHAPTER> element onto the internal formatting language <H1> or
whatever. All that would be required is a hash table and a rudimentary
(non-validating) parser capable of finding start and end tags, and
attribute names. Most documentation going across the 'net will have
been validated already, and most of the documents will be highly
structured, so in many(most?) cases, the DTD will not even be
necessary.
I imagine a situation where the browser (Mosaic for example), might
have a stock of such stylesheets, and can negotiate on which to use
(do any clients use the negotiation stuff in HTTP?), or download a
copy if it doesn't have the correct stylesheet. Given that the browser
is not required to be a validating SGML parser (valid, I think), there
is no reason whatsoever that the browser could not be at least as
fast as the HTML based browsers of today.
But then, I too might be seen as a raving SGML maniac in some
circles... :-)
nick