Message-Id: <email@example.com> Date: Mon, 23 Sep 1996 14:13:24 -0500 To: Foteos Macrides <MACRIDES@SCI.WFBR.EDU> From: firstname.lastname@example.org (Murray Altheim) Subject: Re: Simple(?) question on obscure comments detail Cc: email@example.com 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:firstname.lastname@example.org> http: <http://www.cambridge.spyglass.com/murray/murray.html> "Give a monkey the tools and he'll eventually build a typewriter."