Re: Inline text/html

Earl Hood (ehood@isogen.com)
Thu, 12 Sep 1996 08:37:04 -0500


Message-Id: <199609121337.IAA16642@bonk.isogen.com>
To: Ingo Macherius <Ingo.Macherius@mwe.hvr.scn.de>
cc: www-html@w3.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 <ehood@isogen.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.