Re: Proposal for <INC SRC="URI"> Element for Compound HTML Documents.

Keith Ball (kball@kballuw.SJF.Novell.COM)
Fri, 9 Dec 94 19:33:16 EST

What would be the impact or cost of requiring HTML v3.0 browsers to
support external entity references? When the SGML transfer work gets
complete, it will contain a method for transferring multiple components
of a document, with the entity references for system object identifiers
translated to URIs.

Is there a simplification, if necessary, to the entity management, that
would make its implementation straight forward, but still provide an
adequate level of support to be useful? Everytime I suggest to
someone a "simplification" or "minimization" to some SGML capability
I get trashed. I hope this is not the case for inclusion of external


> From Marc Salomon <>
> Proposal for <INC SRC="URI"> Element for Compound HTML Documents.
> 1. Problem
> The maintenance of a resilient tree of static HTML documents (which is
> indeed appropriate on occasion) requires the ability to make abstractions
> of a series of regularly occuring elements in a set of related documents.
> In a current reference server implementation, Rob McCool has implemented
> Server-Side Includes as an option to CGI for allowing server-side dynamic
> customization of HTML documents transmitted. Reserving exclusively the
> responsibility for dynamic document generation to computational cycles at
> the server can potentially prove problematic at high-volume sites serving
> up tens--perhaps hundreds of thousands of requests daily. If the client
> is going to parse the document in any case, why not allow the
> content-provider the choice of avoiding a parsing session on the
> server-side, if at all possible and desirable, and allowing the client to
> download and assemble the various components of and render the resultant
> document.
> If we could expect most HTML rendering agents to be fully compliant SGML
> applications, complete with entity managers, then the obvious solution
> would be to use the entity manager and catalog to cache-manage recurring
> shared HTML fragments. But since we need immediate measures yesterday to
> solve the looming problems of tomorrow in order to make large-scale
> information provision on the web managable, efficient and feasible until
> we can migrate to a fully compliant SGML or HyTime environment, I propose
> a measure to allow the content provider more freedom in managing and
> specifying the logical content of their documents. Although I am not a
> client-side developer, it seems apparent to me (confirmed by our browser
> expert) that most all the code needed to resolve these issues already
> exists in the leading source distributed browsers.
Keith Ball Unix/SMTP mail:
Building 1 MHS mail: KBALL@NOVELL
2180 Fortune Drive
San Jose Fortune (
(408) 577 8428
Fax: (408) 577 5855

Novell, Inc.

-- sent via the LAN WorkPlace Mailer