You can XInclude anywhere you want to. You just can't do it as part
of an XSLT transformation. Consider this XML document. Call it
document A.
<p>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="somefile.xml" />
</p>
Now consider this XSLT stylesheet (Call it stylesheet B):
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xi="http://www.w3.org/2001/XInclude">
<xsl:template match="xi:include">
Hey diddle diddle
the cat and the fiddle
The cow jumped over the moon
</xsl:template>
</xsl:stylesheet>
When I apply the above stylesheet to the above XML document, I know
what I expect. The XSLT specification leaves no room for doubt.
The algorithm is deterministic. If a program receives document A and
applies document B to it, and the output depends on what is in
somefile.xml, then that program, whatever it may be, is not a
correctly functioning XSLT 1.0 processor. It may be doing something
else useful, but it is not doing XSLT.
I may choose to process the XInclusion to generate a new different
document, C. If I pass C to the XSLT processor along with stylesheet
B, I'll get different output. But this output is not the result of
transforming A. It's the result of transforming C, a very different.
An correctly functioning XSLT processor has to be able to transform
document A and document C. It need not concern itself with how either
document was produced. It must not do anything except what the XSLT
specification indicates though. It must not automatically transform A
into C.
At my SD2002 West talks last week I noticed an interesting
phenomenon. Normally as time passes, new users become more
comfortable with new concepts and technologies like Java, OOP, UML,
and so forth. E.g. new users of Java have less trouble learning it in
2002 than their counterparts did in 1995. A lot of the basic ideas
are "in the air" and students are more willing to take Java on its
own terms rather than trying to force it into preexisting C++ molds.
Now here's what weird. XML seems to be following the reverse pattern.
The students I'm seeing today are having a lot more trouble
understanding XML than the students I taught in earlier years. I
think a lot of that has to do with their struggle to build a
conceptual model that encompasses the rapidly growing number of XML
specifications. They enter with the impression that they have to use
XInclude and XLink and schemas and 12 other things that didn't even
exist two years ago. They see this as a sort of undifferentiated mass
of what makes up XML. They do *not* see this as a set of layered
technologies that they can apply or not in the order they see fit.
Two years ago I could just teach XML. Now I have to both teach XML
and disabuse students of a lot of the mistaken preconceptions they
have about all the supplementary options like XInclude. Tools that
deliberately mix options like XInclusion or schema processing without
an explicit user request do not help matters.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.cafeconleche.org/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+
