Thanks for the reply
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 .
Load data from database, data in user defined cache.
(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).
The entire system is based on xslt stylesheet, we are trying to see if there
is a way to speed up the system. Actually I'm trying using xalan but it seems
so much slower than xsltproc. Maybe I'm doing something wrong in the test
because execution time of xalan is 10 time the one of xsltproc. It sound
strange to me.
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.
Yes, we would like to move to another xslt processor only if there is a faster
xslt processor that xsltproc
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.
Saxon seems as slow as xalan. Maybe I'm wrong here too.
I must say that we don't have big xslt or big xml, but a lot of small xslt
(max 300 rows) and small XML.
regards.
Giulio
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--