Message-Id: <199609121337.IAA16642@bonk.isogen.com> To: Ingo Macherius <Ingo.Macherius@mwe.hvr.scn.de> cc: firstname.lastname@example.org Subject: Re: Inline text/html In-reply-to: Your message of "Thu, 12 Sep 1996 11:32:07 +0200." <199609120932.LAA03493@ESAMX6.mwe.hvr.scn.de> Date: Thu, 12 Sep 1996 08:37:04 -0500 From: Earl Hood <email@example.com> > > As suggested years ago, the SUBDOC entity construct provides > > what you require: > > > > <!DOCTYPE HTML [ > > <!ENTITY otherdoc SYSTEM "http://foo.org/doc.html" SUBDOC> > > ]> ... > > &otherdoc; > > This would include a full HTML document, including <HTML><HEAD><BODY> > sections which are clearly illegal at this point. No it is not. That is not how SUBDOC works. As you have noted, subdoc entities are complete documents. I believe what you are refering to is applicational rendering issues. There are various way to dealing with rendering issues in a resonable manner. > Even if you leave them out a conforming SGML application would insert > them doing the omittag rules. In my feeling SUBDOC is a great idea > to apply to HTML but in the moment I don't see a way to do it legally. There is no issue about legality. It is legal. Period. Check ISO 8879. What needs to be addressed is how to render the subdocument. I wonder if CSS deals with the possibilites of subdocuments, or if it can be easily expanded to deal with subdocuments. Or we can try DSSSL. Or browsers can create their own hard-coded styles as they normally do ... > Using non-subdoc entities is a solution, but it raises the problem --------^^^^^^^^^^^^^^^^^^^ I.e. "SGML text entities" > of entities that are not balanced in the way that they may open > /close tags they did not close/open themself. That is an authoring issue, but a resonable issue for authors to recognize. > I think this is a very > common case, as most includes are headers/footers. SUBDOC would forbid > this as it requires the included document to parse ok to it's own > DTD. SGML text entities can be verified within in the context they are to be referenced. If an author chooses to use entity references for parts of a document, and SGML editor (or an SGML parser) can perform validation to insure the entity will be valid where it is referenced. For simple header/footer capabilities, simple SGML text entities would suffice; subdoc may be overkill (and maybe not). > The W3C HTML DTDs already use parameter entities to simplify the > notation of content models. Why not assign those models > a document type and describe them in an own DTD ? I remember there was > an effort to modularize the HTML DTD (by Murray Altheim) which is suspended > now. Why ???? Do not know why. ... > Having those handy it's easy to write HTML docs which are seperated in > several files using SUBDOC as suggested. > > <!DOCTYPE HTML [ > <!ENTITY section1 SYSTEM "http://foo.org/section1.html" > SUBDOC -- of type DIV --> > <!ENTITY section2 SYSTEM "http://foo.org/section2.html" > SUBDOC -- of type DIV --> > <!ENTITY payload SYSTEM "http://foo.org/payload.html" > SUBDOC -- of type SPAN --> > ]> Of course, and a great use of subdoc since different authors may be responsible for different portions of the document. Since subdoc is a complete document, the document can be published by itself without worry about what other documents may reference it as a subdocument (issues about the SGML declarations ignored for this discussion). Ie. I want the ability to reference an entire html document (ie. doctype = html) along with possible other documents of a different doctypes (eg: div, span, etc ...). For implemntors of WWW software, at least subdoc support can be done for HTML doctypes and doctypes that are subsets of HTML. This requirement should not be too difficult for major companies like Netscape and Miscrosoft. If not subdoc, at least general text entity support. --ewh (and still waiting for entity support) P.S. BTW, subdoc also guarantees separate name spaces. Hence, entities I define in the base document will not conflict with entities of the same name in the subdocument.