cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uli Mayring <>
Subject Re: To contrib or not to contrib
Date Sun, 09 Jul 2000 12:45:59 GMT
On Sun, 9 Jul 2000, Jeremy Quinn wrote:

> Maybe the XFP TagLib could provide an alternative.
> You would be able to pull out just the XML Nodes you want using XPath, in
> one pass, without having to compile your data into XSP. Saving the massive
> overhead of re-compiling your XSP every time your archive receives a new
> message and overcoming the problem of too much data. But, since the syntax
> of the TagLib is based around Forms, the XSP that provides your view of
> your data will look a bit odd :)

I'm not sure this would work, but it sounds interesting. Basically I have
a XSP/XSL stylesheet, which looks like this (pseudo code):

<xsl:template match="root-tag-of-original-XML-file">



<xsl:template match="*">
     <xsl:copy-of select="."/>

As you can see I do a little custom logic, which introduces some new
tags and then I copy all the original tags from the XML file unchanged.
The resulting XML document is then passed to the XSLT-to-HTML stylesheet,
which is specified in the second line of the template body above.

What you suggest (if I understand it correctly) is that I remove the
second template and change the first:

<xsl:template match="root-tag-of-original-XML-file">
     ... as before ...



The same thing could theoretically be done with the XInclude processor, if
instead of the call to your taglib I placed a call to the XInclude
processor. However, since XInclude will always run before XSP, I think the
Xincluded XML will actually be compiled during the XSP pass, thus not
solving the problem. So I will try out your idea, when the taglib is

One problem, however, might be performance: I load the original XML twice
from disk and parse it twice, too.


Ulrich Mayring
DENIC eG, Softwareentwicklung

View raw message