- From: Gavin Nicol <gtn@ebt.com>
- Date: Tue, 29 Oct 1996 17:11:03 -0500
- 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