auto/embed is not node transclusion

[Paul Prescod]

[hopefully of interest to the three lists referenced...]

Rick Geimer wrote:
> 
> While I agree in principle with the notion that it is generally a bad idea to
> create markup that specifies a behavior, there are many real world examples
> where this is the only practical thing to do. 

I agree.

> I will use as an example the
> exchange standard for the Semiconductor industry, ECIX (formerly known a
> Pinnacles, or PCIS).
> 
> ...
>
> For this to work, the standard had to specify a <reflection> element with a
> predefined behavior, i.e. take the contents of the element who's id matches
> the reflection's idref and redisplay it inline at the location of the
> reflection element...the same idea as show="embed" and actuate="auto", if I
> understand XLINK correctly.

I don't think you do understand XLink correctly. Many people make this
mistake. I did for a long time myself. I presume that the semantic of the
"reflection" element is node-level transclusion. In other words,
applications (not just browsers) built on top of Pinnacles probably act as
if that other element has been copied element for element, character for
character, etc. XLink doesn't support that.

XLink describes a data model that includes concepts of "anchor" and
"link." It does not have a concept of either text-level or node-level
transclusion.

First let me define node-level transclusion: node level transclusion is a
transformation from a source grove (DOM, information set, whatever) to a
result grove (...) that creates a result where the result grove has some
nodes replaced by nodes reference by those nodes. This would have
well-defined implications for hypertext links, APIs, stylesheet languages
and so forth. In other words, it would be *well-defined*.

A few months ago I started defining a transclusion mechanism for XML but
there is a problem with differentiation references to the pre- and post-
transformation document. I'm not clear if the XML world is ready to accept
the fact that this kind of hard problem requires an equivalent to the
grove model to be solved. My impression is that the W3C is not properly
constituted to handle abstractions instead of languages but the
information set project provides partial evidence that this might not be
the case.

Now let demonstrate that XLink does not provide transclusion. First, it
does not specify a data model for the result of a transformation. Second,
the things it links to are not restricted to XML elements. In other words,
XLink can embed JPEGs, MPEGs and other data that does not have a concept
of nodes (unless we import the ISO concept of groves and property sets for
them). Therefore we *cannot* in general interpret the grove mode in terms
of a grove to grove transformation. 

You could argue that I am being a purist. Embedding PDFs or JPEGs would
"probably" have the behavior of just *displaying* them inline but
embedding an XML element would have the behavior of node-level
transcluding it. Browsers would "probably" implement it compatibly. Are
you comfortable with these probably's and with trusting the
like-mindedness and good will of browser vendors? If so, let me ask a few
questions:

 * what if someone does NOT want node-level transclusion but instead want
XML documents and elements to get the same kind of figure-style
transclusion that PDFs or graphics would get?

 * what does the input of an auto/embed transclusion look like from the
stylesheet or DOM?

 * what does an idref-based hyperlink into the embedded document look
like? What does it mean if the inclusion duplicates an ID?

 * how do you reference (from an XPointer) the reference-defining element
instead of the referenced element in the result tree?

 * is the validity of the resulting document checked? is a valid referent
of an XPointer that is restricted to pointing to *valid* documents of a
particular type?

 * does user/embed mean that when you "invoke" the link the document
structure changes? Should stylesheets be automatically reapplied? Does the
DOM change? etc.

I am not very confident of interoperable implementations by the major
browser vendors. Personally, I feel that I would rather wait for a real
transclusion mechanism even if it means I have to wait for a W3C grove
model and addressing mechanism that can differentiate a reference to an
input document from a reference to the result document.

If you want to use a stylesheet to *render* auto/embed as node-level
transclusion (and answer all of these questions in your stylesheet) then
you certainly can. But the transformation you have chosen is not at all
mandated by the XLink specification. Someone else could implement it
differently and be just as right (or wrong) as you.

So is half a standard better than none? Debatable. When it comes to
linking, XLink does everything you need. Without behavior it is a
beautifully small, simple and complete specification.
 
> I don't think it would be appropriate for a standard to mandate a particular
> stylesheet language along with the markup to make this work (though the only
> way I have been able to get this to work with any XML tools today is with
> XSL). 

Nor do I. I think we need real node-level transclusion desperately. I also
think that it is a hard problem that must be solved properly after
implementing the proper logical infrastructure. XLink doesn't do it and it
probably wasn't meant to.

Transclusion and linking are different. Their underlying data models are
different. Linking is about describing a relationship between two nodes.
The data model is "link", "locator", "anchor". Transclusion is about
building a new grove from an old one. The data model is about "source
tree" and "result tree." 

If XLink was meant to be interpreted as node-level transclusion then
either the XLink or XPointer specification would mandate the meaning of a
reference into a transclusion-expanded document.

> If this
> kind of link behavior can be specified in a standard way with XLINK, all the
> better.

I hope by now that I have demonstrated that it cannot be.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

Earth will soon support only survivor species -- dandelions, roaches, 
lizards, thistles, crows, rats. Not to mention 10 billion humans.
	- Planet of the Weeds, Harper's Magazine, October 1998

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)