In general, if there's an SGML way of doing something, especially if
that way is widely supported and is clearly described in the standard, I
do think it's best to use it.
I think SUBDOC has a couple of problems, although I'm not ruling it out.
These are
(1) that it is not widely supported by SGML software
(2) that it raises issues of SGML entity management.
(3) it can raise problems for style sheet implementations if the
included document uses a different style sheet from the current one,
and there are conflicts; this can be resolved, though.
In addition, an <INC> element could have content, e.g.
<INC HREF=".....">This is a short description</INC>
Note that we don't support arbitrary SGML documents, strictly speaking,
in SoftQuad Panorama -- and neither do the other SGML vendors.
No-one (as far as I know) implements all of SGML in a browser.
Whenever you change the SGML declaration, you enter dangerous territory.
I suppose that we could have something like the HTML Accept: protocol for
specifying SGML Feature Set numbers, but there aren't any servers that would
use it, I think.
For now, we don't support changing the SGML declaration in Panorama,
although the one we use has various limits (e.g. NAMELEN) increased a lot,
and we don't check CAPACITY.
Of course, we could add SUBDOC, but there are some problems. In particular,
the style sheet issue is a real one, and there are issues to do with entity
management. But it could be done.
You'd have to declare the other file as an SGML entity (I think --- I am
at home & am writing from memory, which has proved stupid in the past).
Current HTML browsers don't have the concept of per-instance entities.
So, although we might think that that would be a good thing, it would
have implications both for browser writers and also for HTML editors.
More thoughts on INC:
I've been toying with the idea of writing a web client and a proxy
server that go together. The proxy would fetch the start of all
documents referred to in anchors, with a limit that it wouldn't
need to fetch any that were more than a couple of screens away
from being visible to the user (for efficiency), and possibly keep an
ndbm-style cache of URL --> Title mappings. Then the client could display
the title of any HTML document that is referred to in an anchor, and maybe
even thumbnails of images.
What I am trying to hint at is that client-side file inclusion is
rather like following an anchor and putting some or all of the information
you find inline.
So maybe this should simply be an extension to <A>.
I also note that SoftQuad Panorama can display the contents of any element---
including sub-elements---in a pop-up window, further blurring the distinction
between files & documents & links. The user clicks on an icon (usually a
picture of a light bulb in Panorama) just like following a link, except that
the data is already there.
Another way to look at this is the ability to delay downloading part of a
large document. This is a bit like `delay loading images'. If you combine
this with the idea of a Virtual Document, made up of many smaller parts,
<INC> and <A> and <DELAY> become very indistinct indeed.
I know that we have had people asking for the ability to download fragments
of documents, and to build them up gradually into larger documents in the
client. (This is for Panorma). So I am certainly in favour of the idea.
I genuinely don't know whether SUBDOC is appropriate, but I think it's
probably not the right way to go. Apologies for rambling a little.
Lee
--Liam Quin, SoftQuad Inc +1 416 239 4801 lee@sq.com <URL:http://www.sq.com/> HexSweeper NeWS game;OPEN LOOK+XView+mf-fonts FAQs;lq-text unix text retrieval SoftQuad HoTMetaL/HTML Editor; SoftQuad Panorama/WWW SGML Viewer (unreleased) See our Web page for HoTMetaL ftp sites... Take off those shoes and relax.