Re: [xsl] XSLTPROC performance

[Abel Braaksma <abel.online@xxxxxxxxx>]

Giulio Rizzo wrote:
> First of all I introduce myself, I'm Giulio from Italy.
>   

Hi, nice to meet you and welcome to the "club", I'm Abel from Holland ;)

> I am required to write some extension function to a libxml compliant xslt 
> processor. 

May I ask you what this extension function is about? Often people write 
extension functions when the same thing is possible with a little extra 
effort within XSLT itself .

> (performance is the highest 
> requirement), 

If this is true you shouldn't use XSLT and XML in the first place. 
Clarity and extensibility have always been higher requirements for these 
languages (and its tools) then performance. I.e., a SOAP bridge (which 
is based on XML) is inherently slower than a RPC bridge (or most other 
alternatives like CORBA and DCOM).

> Is any other solution alternative to the two I've mentioned? The problem is 
> that is about 6 years that XSLTPROC have been used and the new (?) processor 
> must give the same results as XSLTPROC.
>   

There are plenty XSLT 1.0 processor around. If your stylesheets are 
written without using extensions, you can reckon that they are quite 
likely XSLT 1.0 compliant and will run with the same results on most 
processors (whitespace, which is insignificant in XML, not counted). Of 
course you'll have to test this to be sure. There are XML comparison 
tools around that will find differences that are significant.

> Last question, the optimum will be to be able to use a java XSLT processor, 
> but I must be sure that it is 100% compliant with the results of an XSLTPROC 
> execution on the same input.

One of the most used XSLT processors these days is the Saxon processor 
(but that's a gut feeling). The older Saxon 6.5 processor (not 
maintained anymore) is 100% XSLT 1.0 compliant and supports many of the 
EXSLT extensions. The newer Saxon 9.0 processor is 100% XSLT 2.0 
compliant. Going to XSLT 2.0 may give you a little trouble in the 
beginning, but many things that were formerly done with extension 
functions or complex recursion have become one-liners in XSLT/XPath 2.0. 
Of interest to you might be the XSLT 1.0 backward compatibility mode 
which makes running XSLT 1.0 code easier.


Cheers,
-- Abel Braaksma