Re: Poor performance of document() in XSL [Was: Re: simpel cocoon question]

2002-11-08 Thread Jeremy Quinn
On Thursday, Nov 7, 2002, at 16:19 Europe/London, Joerg Heinicke wrote: normally this won't work. You create a Result Tree Fragment in $colours and have to convert it to a node set using node-set() extension function. This is not possible when using XSLTC. Sorry for the red-herring! I did n

Re: Poor performance of document() in XSL [Was: Re: simpel cocoon question]

2002-11-07 Thread Jeremy Quinn
On Wednesday, Nov 6, 2002, at 21:26 Europe/London, Stephen Ng wrote: I say, document() is good for rapid prototyping, but is a poor choice for final deployment for performance reasons. Use aggregation instead. The Cocoon developers recommend to use aggregation or xinclude because of SoC (XSLT

RE: Poor performance of document() in XSL [Was: Re: simpel cocoon question]

2002-11-06 Thread Stephen Ng
> > I say, > > document() is good for rapid prototyping, but is a poor choice for > > final deployment for performance reasons. Use aggregation instead. > > The Cocoon developers recommend to use aggregation or > xinclude because of SoC (XSLT is for transforming, not for > aggregating content).

RE: Poor performance of document() in XSL [Was: Re: simpel cocoon question]

2002-11-05 Thread Leigh Dodds
A naive implementation of the document() function is likely to do this. However happily, by implementing the javax.xml.transform.URIResolver interface [1], and setting this on the Tranformer using setURIResolver [2] you can easily plug in a simple cache (e.g. hash of URL versus retrieved content) t