Re: Transclusion

At 10:43 PM 10/28/96 GMT, Charles F. Goldfarb wrote:

>Transclusions accessed via a general entity reference (meaning &entname;)
>violate 8879.

>Transclusions accessed through an attribute value do not violate 8879.

The Term transclusion comes from Nelson's seminal book Literary Machines,
and refers to a characteristic at the user level, not the parser level. The
interactional semantic called transclusion doesn't care whether you parse
the referenced data in the referencing context or not. The notion of
"parsing context" is SGML-specific, and is itself out of context when
discussing transclusion. For many cases of transclusion, the referencing or
the referenced data, or both, may be in media that have not even have an
applicable notion of "parsing". 

The first statement quoted above amounts to saying "an SGML-based system
must never display a referenced entity's content at the point of reference."
I disagree; indeed, that's exactly what SGML systems do with data included
via entity references all the time. It would instead be more correct to make
the weaker claim that "entity reference is the only means of transclusion
supported directly by a bare SGML parser": since the defined behavior is to
go fetch the entity and deal with it right then, which not only gets the
effect of transclusion but *prevents* any other effect (unless your parser
tells your application non-ESIS information about where the entity reference
occurered, so the application can hide it). 

In short, entity reference *is* transclusion, though of limited capability.
SGML imposes limitations on what data you can transclude this way, and thus
you cannot accomplish all the kinds of transclusion you want -- for example,
if Charles means that referring to an entity in an invalid context for it is
invalid, he's right -- but that's not what anyone has in mind, I think.

If what Charles has in mind is that an SGML system cannot defer parsing the
content of the referenced entity until later (say, when the user click on an
icon), that is true, but is only a fact about *parsing*. An SGML system may
choose to parse the data and then hide it until the click occurs -- lots of
SGML systems do that every day. The SGML restriction does prevent a system
from optimizing its performance, but that has little to do with transclusion
(if the data is hidden behind a link that must be manually activated, it is
not textbook transclusion anyway).

Obviously in SGML you don't *parse* <INCLUDE entity=foo> the same as you
parse &foo;.  But anyone who wants to is free to state that the intended
semantics of their <INCLUDE> tag is transclusion, so you can get the same
user-level effect from <INCLUDE> as from &foo;. An application sitting on
top of an SGML parser can respond to an entity named on a ENTITY attribute
any way it likes, from discarding it entirely, to fetching it and displaying
it to the user in between where it displays the SGML data that occurred
before and after the reference. It's semantics, not parsing. 

Scrapping entity references is thus preferable to scrapping ENTITY
attributes, because with attributes you can handle more kinds of referenced
data, and an implementation is not forced to fetch data that it may, in the
end, not need. Style and other semantics can be defined to work across the
entity boundary.

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.

s

Received on Tuesday, 29 October 1996 14:01:05 UTC