Re: Simple(?) question on obscure comments detail

Murray Altheim (murray@spyglass.com)
Mon, 23 Sep 1996 14:13:24 -0500


Message-Id: <v02110109ae6c8c1c052e@[192.168.22.85]>
Date: Mon, 23 Sep 1996 14:13:24 -0500
To: Foteos Macrides <MACRIDES@SCI.WFBR.EDU>
From: murray@spyglass.com (Murray Altheim)
Subject: Re: Simple(?) question on obscure comments detail
Cc: www-html@w3.org

Foteos Macrides <MACRIDES@SCI.WFBR.EDU> writes:
>        OK, so to continue this lesson, how would the modular DTD
>work, i.e., what would be the structure of an "HTML _file_" which
>uses it, and can it internally avoid foul ups for currently
>deployed (but not *too* old) browsers, or would providers *need*
>to have two different versions of documents offered on the basis
>of content negotiation?  If this requires too long an answer, put
>off the question about content negotiation, for now, and hopefully
>get across the basic concept of a modular DTD for plain folks. :) :)

The modular DTD has no impact on most processes -- it looks to a parser
like any other DTD. It's simply broken up into separate file components
(DTD fragments) which are concatenated by an entity manager into a final
DTD document prior to parsing the document instance. Those who wish to muck
with it could add or subtract components, generally by declaring marked
sections within the DTD to turn features (such as frames or math) on or
off.

Every variation of the DTD would require a variant formal public identifier
(FPI: the "-//IETF//DTD HTML//EN" thingie), as every unique piece of public
text requires a unique public identifier. This would entail potentially
limitless variants of a specific reference DTD. I had begun working up the
draft of a scheme for identifying DTD variants in an ordered manner, but
this is on hold (as is the modular DTD draft).

Since last winter, James Clark (author the SP (an SGML parser) and Jade (a
DSSSL engine), and an editor of the DSSSL standard), has made strides in
describing and implementing architectural form support in SP. Architectural
forms are a feature in the HyTime standard (ISO/IEC 10744). An
"architecture engine" would enable processing of a meta-DTD, with included
subclassed DTDs. Theoretically, an HTML meta-DTD would encompass all common
variants of HTML and allow validation against a base architecture. The idea
of a modular DTD fits into this schema by allowing a common reference DTD
upon which to build subclassed DTDs.

It will probably be awhile before we see this in products, but it is the
direction some of us are heading.

As for content negotiation, when browsers begin (someday in the 23 1/2
century) to parse DOCTYPE declarations, the DTD of the document will
matter, and I assume the browser will change its rendering behavior to
match its understanding of the document as based on document structure
defined in the DTD. Until that time, "Babes on the Web" RULES!!! (sorry,
just some Monday sarcasm)

Murray

```````````````````````````````````````````````````````````````````````````````
     Murray Altheim, Program Manager
     Spyglass, Inc., Cambridge, Massachusetts
     email: <mailto:murray@spyglass.com>
     http:  <http://www.cambridge.spyglass.com/murray/murray.html>
            "Give a monkey the tools and he'll eventually build a typewriter."