>Keep in mind the distributed computing issues: caching, round trip times...
>Integrating a full-fledged SGML entity manager with the web I/R protocols
>might be a good idea, but I have thought about it a lot and so far
>failed to come up with a strategy that I'm happy with.
The main distinction I am trying to make is that <A> and <LINK>
effectively involve content replacement for HTML documents, and
<INCLUDE> has the same semantics. System entities on the other hand
load parts of one larger document.
Now if one treats <INCLUDE> as an element which loads in a complete
document, I do not find it objectional, but if it is to be used to
pull together peices of a single document, then it is most
distasteful, because it could potentially lead to the severe violation
of the content model (particularly as HTML becomes more structured)
and it will be somewhat complicated to perform validation using
standard tools.
To illustrate what I mean:
<A HREF="http://foo.bar/baz">Foobar</A>
In effect causes the creation, and display of a new document object
when the system detects that link has been activated.
<IMG SRC="http://foo.bar/baz.gif">
Results in a GIF image object being created and embedded in the
document object being displayed.
<INCLUDE "http://foo.bar/section-1.1.html" REL="EMBED">
If this results in a new document object being created, and then
that object being embedded (inlined), much like <IMG>, then I have
no objections, because these individual documents can be verified by
the parser.
If this results in the "section-1.1.html" being inserted at the
current position in the textual representation of the document
object currently being loaded/displayed, then we have complicated
the parsers and entity managers by making them very context
sensitive, and worse, we set a precedent for such usage.
>The <a> element was conceived to cover all these cases.
>(The only thing I'd change is to allow a <as id=x1>...<ae id=x1> pair
>as an alternative to <a>...</a> for cases where anchors overlap
>elements...)
Introducing asynchronous behaviour into the DTD is not
recommended, as again, it complicates the parser/renderer no
end. Worse, it makes it *very* hard to do sub-document addressing,
because we have to look at the entire ancestry of an element to decide
how to process it. Such "element pairs" have appeared in many DTD's,
and almost all of them later removed them. HyTime constructs might be
more useful...
