Re: Proposed SUBDOC support in HTML

Daniel W. Connolly (
Tue, 23 Aug 1994 23:27:05 +0200

In message <>, Earl Hood writes:
>(I'm unsure what is the appropriate list for this message; any follow-ups
> to the appropriate mailling list).

[Follow-ups redirected to, the general HTML
discussion list. We should also include the comp.text.sgml group
in this discussion somehow, as they're currently mulling over practical
applications of HyTime, ways to improve SGML, and ways to clean
up the design and enhance the features of HTML.]

>Since there exist the a push for HTML to be SGML compliant, It might
>nice if HTML supported the SUBDOC feature of SGML.

I'm not sure what you mean by this. It's awkward, if not meaningless
to say "HTML supports X." You might say "it would be nice if HTML
browser supported SUBDOC by...".

It is, however, meaningfull to say "The HTML DTD and accompanying
SGML Declaration should allow SUBDOC," which they currently don't.

> I believe SUBDOC
>support will make it easier to maintain larger HTML documents with
>muliple contributers.

I agree. I'd like to arrange the "nodes" of my document in separate
document entities, serve them up separately as today, and parse
them all at once for printing etc. using SUBDOC.

>On a related note, if SUBDOC support is too messy, or undesired, how
>about allowing the HTML element to contain other HTML elements. I.e.
>An HTML document may contain multiple HTML documents (an ugly sentence,
>but you get my point). DocBook has such a declaration in its DTD. It
>might seem strange, but it does have its uses.

I'd rather see other elements besides the HTML element allowed as the
document element, or "root" of an HTML document, e.g.:

<DOCTYPE paper PUBLIC "-//IETF//DTD HTML//3.0" [
<!ENTITY ch1 SYSTEM "ch1.html">
<!ENTITY ch2 SYSTEM "ch2.html">
<title>Big Paper</title>


<chapter content=ch1>
<chapter content=ch2>

then in ch1.html

<DOCTYPE chapter PUBLIC "-//IETF//DTD HTML//3.0">
<title>Chapter 1</title>

and similarly for ch2.html

I'd like to see HTML 3.0 support the full range of LaTeX document
types -- paper, article, book, etc. plus perhaps RFC.

Using a set of architectural forms to build the DTD would simplify
the design of browsers so that they wouldn't need explicit knowledge
of all the "semantic" tags like <abstract>, <author>, and stuff
like that.

But let's do capture the common communications idioms that are current
practice (outside of HTML...), and let's think about the distributed
computing aspects of shipping bits and pieces of documents over the
wire at different times as we design new DTDs.

I think we should look seriously at systems like QWERTZ and gf

(see file:// for gf source)

that capture LaTeXish idioms in SGML.