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

[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 not actually test it, I should have .

regards Jeremy


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

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

[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 is for transforming, not for
aggregating content).


Sure, but I have a big lookup table in an xml file--it seems much more
natural to reference the lookup table from xslt using document rather
than to jam it into my content stream


You may find, if you re-encode your lookup table as XSLT variables, 
that you can 'include' your data as XSLT into your stylesheet.

eg.

constants.xslt:

	
		#fff
		#000
		#888
	

main.xslt:

	

	..

	
		
		
			


			
		
	

Hope this helps

regards Jeremy


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

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

[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).

Sure, but I have a big lookup table in an xml file--it seems much more
natural to reference the lookup table from xslt using document rather
than to jam it into my content stream

--Steve

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

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

[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)
that avoid multiple network overheads.

I have a sample implementation and simple test harness
if anyone wants it.

Cheers,

L.


[1]. http://java.sun.com/j2se/1.4/docs/api/javax/xml/transform/URIResolver.html
[2].
http://java.sun.com/j2se/1.4/docs/api/javax/xml/transform/Transformer.html#setURIResolver(javax.xml.
transform.URIResolver)

> -Original Message-
> From: Ilya A. Kriveshko [mailto:ilya@;kaon.com]
> Sent: 05 November 2002 14:33
> To: [EMAIL PROTECTED]
> Subject: Poor performance of document() in XSL [Was: Re: simpel cocoon
> question]
>
>
> SAXESS - Hussayn Dabbous wrote:
>
> > 
> > But you also could do it directly within the xslt context:
> > You can use the document() function in your XSLT-file.
> > This function allows you to refer to data contained within
> > another XML-file. This is completely decoupled from cocoon
> > though. It's more about how to work with XSLT:
> > 
>
>
> In the past I have encountered a nasty performance problem with document().
> For example, when you declare an xsl variable that gets its value from a
> document(),
> and then use its value several times throughout the stylesheet, the URI
> of the document
> gets hist as many times as there are references to that variable. I.e.
> the xsl variable
> does not store the XML fragment it was given at the variable definition
> time, but
> merely stores the XPath string and then resolves it every time it's
> referenced.
> This may or may not be true for XPath expressions that do not contain
> document()
> as well. Does anyone know for sure?
>
> Example:
>
>  select="document('cocoon:/gimme-sumthn')/sumthn/in/@there"/>
>
> 
>   
> 
> 
> 
>   
> 
>
> When using Xalan, this example will cause the Cocoon pipeline that
> is responsible for "gimme-sumthn" to be hit three times. I say,
> document() is good for rapid prototyping, but is a poor choice for final
> deployment for performance reasons. Use aggregation instead.
>
> +2c
> --
> Ilya
>
>
>
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

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

[Ilya A. Kriveshko]

SAXESS - Hussayn Dabbous wrote:



But you also could do it directly within the xslt context:
You can use the document() function in your XSLT-file.
This function allows you to refer to data contained within
another XML-file. This is completely decoupled from cocoon
though. It's more about how to work with XSLT:




In the past I have encountered a nasty performance problem with document().
For example, when you declare an xsl variable that gets its value from a 
document(),
and then use its value several times throughout the stylesheet, the URI 
of the document
gets hist as many times as there are references to that variable. I.e. 
the xsl variable
does not store the XML fragment it was given at the variable definition 
time, but
merely stores the XPath string and then resolves it every time it's 
referenced.
This may or may not be true for XPath expressions that do not contain 
document()
as well. Does anyone know for sure?

Example:




 
   
   
   
 


When using Xalan, this example will cause the Cocoon pipeline that
is responsible for "gimme-sumthn" to be hit three times. I say,
document() is good for rapid prototyping, but is a poor choice for final
deployment for performance reasons. Use aggregation instead.

+2c
--
Ilya





-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>