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.
A proposal follows that allows for the content provider to decide, based
on the resources available, whether the client or the server should build
compound documents. The server-side scheme has been described elsewhere.
The client-side scheme would be based on URI (de)referenced HTML
fragments that would be obtained in the same manner (and hopefully with
much of the same code) as inline images are, with an HTTP GET (or HTTP-ng
Multiplexed GET method) and injected into the HTML stream. Potential
benefits of this scheme include the flexibility afforded content
providers to manage their collections effectively, allowing the re-use of
common HTML. An efficient client would naturally cache most common
fragments in a domain (like menubars headers or footers for example)
which would avoid the only forseeable performance downside: several tiny
HTTP transactions under
HTTP/1.0. For HTTP/1.0 and HTTP-NG as sketched, there could be a small
tiny-packet penalty, incurred once. The potential for specifying a
series of fragments that would compile into bad HTML exists, but is no
more of a danger than current practice of allowing a content provider to
serve up bad whole HTML documents.
Here are the 71 bytes that I would propose adding to the HTML 2.1 (and
eventually evolving to the HTML 3.0) DTD:
<!ELEMENT INC - O EMPTY -- Embedded HTML -->
<!ATTLIST INC SRC %URI; >
Usage:
...
..
Would implementing this tag and including the results of the dereferenced
URI in the HTML stream rendered by the browser make life unliveable for
browser developers? If so, would that living hell be more than an order
of magnitude less than the increased functionality provided information
providers?
Future:
I would also like to extend this for 3.0 so that bounded sections of an
other document could be included as well. Perhaps some form of this tag
that would contain a URI as well as two named anchors (data between which
would be imported) would work for that. Dave Raggett mentioned to me at
the html-wg in San Jose that the FIG tag could work for this It seems to
me that unless you wanted to treat the included HTML as an alignable
widget (which could be cool) with the same extensive presentational
attributes as FIG, that using FIG would be overkill.
-marc
--