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.
Chris Lilley wrote:
> On the other hand if you could put up arbitrary SGML, with a link to the
> DTD and the style sheet in the header, and if a browser (using the
> distributed flock of cooperating services model) hauls in an SGML parser
> to deal with it, that would be good.
>
> HTML+ then would become a lingua franca, efficient because you don't need to
> send over the DTD, while richer DTDs could be used for documents where you
do
> need the structure to be kept intact.
Has anyone ever considered specifying HTML+ in terms of an underlying
architecture? I don't know how many of this list's readers are familiar
with "architectural forms", but it seems to me that this might be a partial
solution to these issues. I agree with the sentiments that full-fledged
style sheets will probably be necessary for some applications. However,
in many cases, it will be much simpler; a new DTD will be necessary so
as to have a richer structural language, but the main presentation concern
is that it be presented sensibly.
One simple way to do that is for the DTD to map elements to HTML+ elements,
essentially telling the browser that it can treat the new elements as
equivalent to certain HTML+ elements. That's a bit inelegant, though ...
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.
(Fixed attributes are declared, with value, in the DTD, and need not be
specified in the document itself). Browsers that *only* support HTML+ can
pretend that those presentation attributes are implicit characteristics
of the elements themselves, but a full-fledged SGML browser would not have
to handle HTML+ specially ... it would choose presentation style based on
those attributes alone.
Here's a quick example (hopefully not too contrived). Say that the HTML+
style semantics are defined in terms of the value of an attribute called
HTML_style. In the HTML+ DTD, the "pre" element would be defined like this:
<!ELEMENT PRE - - (%text;)+ -- preformatted fixed pitch text -->
<!ATTLIST PRE
id ID #IMPLIED
charset CDATA #IMPLIED
HTML_style NAME #FIXED pre >
This means that the PRE element is presented in the "pre" style in the
HTML+ architecture.
Now, assume I'm writing a document which includes a complete example C
program, broken into pieces, with explanation for each piece. It also
contains example output of the program, so I don't want to just use <PRE>
for everything, lest it get confused. In my new DTD, derived from HTML+,
I could do this:
<!ELEMENT CODE-FRAG - - (%text;)+ -- preformatted code fragment -->
<!ATTLIST CODE-FRAG
id ID #IMPLIED
charset CDATA #IMPLIED
HTML_style NAME #FIXED pre -- format this like a PRE element -->
Then I could put all the code fragments in CODE-FRAG elements. The browser
could learn from the DTD that, for all CODE-FRAG elements, the value of
the HTML_style attribute is "pre", and present those elements accordingly.
Of course, a general style-sheet facility could still be layered on this,
and would probably be needed eventually. But this seems like an easy first
step. It permits browsers which have more advanced SGML knowledge, but
which needn't also have a complicated style-sheet facility; they just
do a simple mapping. And it fits what Chris was saying ... HTML+ remains
simple and efficient. The architectural mapping is there in the DTD, but
simple browsers which only speak HTML+ can treat them as inherent
characteristics of the elements, and ignore the DTD altogether.
Regards,
---Glenn