W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > October 1996

Re: Transclusion

From: Gavin Nicol <gtn@ebt.com>
Date: Tue, 29 Oct 1996 17:11:03 -0500
Message-Id: <199610292211.RAA00642@nathaniel.ebt>
To: sjd@kirk.mit.edu
CC: w3c-sgml-wg@w3.org
>So I agree with Charles, namely that we're better off with ENTITY attributes
>-- but I don't think the reasons have much to do with 8879 conformance.

Well, the point I was trying to make is that if we have synchronous
entities, there is nothing *stopping* the parser from performing the
nice optimisation of fetching the entity, and parsing it, only
when needed. In other words, the application built on top of the
parser may never even be aware of when the entities are resolved and
parsed (a nice feature in some systems). On the other hand, using
element + ENTITY attributes requires the application to resolve the
entities as needed (a nice feature in other situations).

I think there is room for *both* forms, but I cannot see why one is
necessarily preferrable to the other for network use. For myself, I
would very much like to use the lazy entity resolution model in an
idea I have for realtime HTML (could be extended to realtime XML).

As for SGML conformance. SGML is *supposed* to be parsed from head to
tail, and entities resolved in the parsing process. This is
actually a *requirement* because entities may be asynchronous with the
document structure (ie. they can drastically alter the structure). 
Once this asynchronisity is removed, there is no need to enforce this
rule because entity resolution cannot affect the document structure
beyond the child list of the element in which the entity is being
resolved. If we restricted entities even further to *requiring* that
there be a single containing element for the entire content of the
entity, then there are even fewer structural changes possible: indeed,
in most implementations, you would have an object that would be almost
identical to the element + ENTITY attribute object. 
Received on Tuesday, 29 October 1996 17:12:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:04 UTC