I guess I better go get the latest version.
> Also, what are your expectations for browser behavior when a
> compound document is accessed? Must all the pieces be retrieved
> and assembled before any is rendered?
That's a tough question, and I do not have the experience in
server/browser development to give the best answer, but here is
a suggestion anyway:
The client can retrieve each SUBDOC in a similiar manner
as it does with inline-images. If HTTP connection is
terminated before all pieces are retrieved, then the client
can render what it did get, and leave markers where the
missing parts are located.
In order for the client to properly retrieve the SUBDOC parts,
the SUBDOC entity declarations will contain the URL to retrieve
the SUBDOC. For example:
<!ENTITY part1 SYSTEM "http://www.org/part1.html" SUBDOC>
I.e. The SYSTEM identifier is the URL of the subdocument. Of
course, the URL can be relative to the base just as with anchors
and images. For example:
<!ENTITY part1 SYSTEM "part1.html" SUBDOC>
Unless I'm mistaken, this approach will require no extra work on
the server's part.
Optimizations can be performed by requiring that subdocument entity
identifiers use the same base URL as the main document (this is next to
impossible to enforce), and the HTTP protocal can be modified to keep
an HTTP connection open for retrieving subdocuments instead of
opening/closing a connection for each subdocument.
--ewh