This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XInclude in Cocoon
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] XInclude in Cocoon
- From: Uche Ogbuji <uche dot ogbuji at fourthought dot com>
- Date: Thu, 08 Feb 2001 15:32:49 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> But thinking about it, isn't there an interesting issue with
> XIncludes in XSLT? If an XSLT processor is presented with:
>
> <xsl:template match="/">
> <foo>
> <xinclude:include href="foo.xml" />
> </foo>
> </xsl:template>
>
> How does the processor know whether the xinclude:include should be
> activated during the parse of the XSLT stylesheet or whether the
> include element should be copied to the result tree?
This is defined by the processor itself.
The XInclude spec defines a way to express inclusions, but makes no
prescriptions of the semantics of such inclusions. An XSLT processor can
choose to expand the include or pass it on, and in both cases be conformant to
XInclude and XSLT.
Yes, this could eb problematic for interoperability.
> >From the sounds of XInclude, I guess that processing the include
> elements is a pretty low-level feature of an XML processor, and that
> the stylesheet's DOM will include the external file.
Not necessarily. The only note that is made is that it is at a higher level
than parsing. But other than that, it could be at a level below DOM, between
DOM and XSLT, or above XSLT.
> Which means that to *create* an include element in the result, you'd
> have to use the xsl:element instruction *or* use a namespace alias. In
> other words, elements and attributes that are dealt with by low-level
> XML processors have to be generated with the same techniques as XSLT
> elements and attributes. As XLink becomes supported as well,
> presumably we'll run into the same issues there.
I think you pretty much bring up an undefined crease between the
specifications. There are many others.
This is what we get until the XML core specs settle down.
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list