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

Re: Transclusion

From: Steven J. DeRose <sjd@ebt.com>
Date: Wed, 30 Oct 1996 12:56:42 -0500
Message-Id: <>
To: Charles@sgmlsource.com, gtn@ebt.com (Gavin Nicol)
Cc: sjd@kirk.mit.edu, w3c-sgml-wg@w3.org
At 12:47 AM 10/30/96 GMT, Charles F. Goldfarb wrote:
>I don't see any problem with this, as long as the external SGML text entity
>doesn't change the parsing state. As David pointed out, the standard doesn't
>address timing, just context. The external SGML text entity would have to be
>parsed as though it occurred as a replacement for the entity reference. The
>following the entity reference has to be parsed as if it followed the
>replacement text. The challenge will be to define (and enforce?) the
>restrictions on a non-state-changing external entity.

Exactly right. The good news is that there is a convenient source for that
information: this information is exactly what the SGML Open fragment
specification (TR9601) provides. It gives a plain-text way to encode the
parsing context of a synchronous fragment, designed precisely so that the
referenced entity's replacement text can indeed "be parsed as though it
occurred as a replacement for the entity reference". 

Likewise, the restrictions we have already imposed in XML (on #CURRENT,
OMITTAG, USEMAP, and so on) let us avoid residual effects ways the
referenced entity to leave on the parsing context of the referencing entity.
The only case I can think of that might not be fully covered is RE handling
state, but our new rule on that almost certainly makes the differenc, if
there is any, moot.

Oh, I should note that for this purpose one must distinguish parsing context
per se, from validation context: although one can parse correctly, one
cannot in this case validate that IDs are unique. Obviously that would
require sending a complete list of the IDs in every directly or indirectly
referened entity, which would be a pretty high cost to gain the ability for
every recipient to validate what was sent, which should have been validated
by the sender ahead of time anyway.

Received on Wednesday, 30 October 1996 13:03:11 UTC

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