[XSL-LIST Mailing List Archive Home]
Re: [xsl] XInclude in Cocoon
Subject: Re: [xsl] XInclude in Cocoon|
From: Daniel Veillard <Daniel.Veillard@xxxxxxx>
Date: Fri, 9 Feb 2001 09:31:25 +0100
On Thu, Feb 08, 2001 at 03:32:49PM -0700, Uche Ogbuji wrote:
> > 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.
Agreed, Xinclude is defined as an operation on Infoset, i.e. parser
results. Nothing is said about when it should be applied. Honnestly,
I doubt that one way would fit everybody's need. And as far
as I can tell toolkits providing XInclude functionnality have 2 operating
- the option of having Xinclude processed directly at parse time
- a function allowing to process XInclude a posteriory at any time
in the life of the document (assuming your document have a DOM
like tree representation with enough informations to process XInclude).
In the case of Xinclude/XSLT, I would in general apply XInclude first,
because it's likely:
- it avoid too much troubles resolving URI references to the
included fragment, which can be nasty on an XSLT result (which
have no Base URI).
- to be more efficient since preprocessing of the include is done
only once per template instead of once per result instance
> > 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.
Well, not that simple, sometimes you just don't want to define
in a rigid way how processing have to be done, especially when all this
are actually new sections of a tool box. It sometimes does make sense
to process first A then B, and in other cases B then A, B and A being
in the pool:
- Schemas validation
- XML Canonicalization
Even when existing spec defines the processing rigidly like DtD validation
well the toolkit sometimes need more flexibility (people do want to
validate a parsed and modified document without necessarilly going back to
my 2 cents,
Daniel Veillard | Red Hat Network http://redhat.com/products/network/
veillard@xxxxxxxxxx | libxml Gnome XML toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list