On Fri, 2008-07-25 at 14:05 +0200, Svante Schubert wrote: > 채정욱 wrote: > > > > Hi Svante, > > > > I have read your information (i.e. “FYI: Enhancing XSLT processing in > > OOo 3 - exchanging Xerces/Xalan duo with Saxon processor”). > > > > I think it is very grateful task for better OOo. > > > > But I am wondering why you are using JAVA XML processor only, not C++ > > version XML processor. > > > > I think if OOo use C++ processor, there is no cost from > > CPPUNO<->JNI<->JavaUNO. > > > > More over, there is already C++ parser(expat, libxml2, libxslt, > > libxmlsec ; related to xmlsec) in OOo pakacage already as you know. > > > > I want to know about your XML processor selection criterion between > > C++ and Java. > > > > And why there are redundant XML processors? > > > > Firstly, I wanna email this question to OOo xml email list. But I am > > wonder if this issue was one of the very old closed one. > > > > If you give me some advise, it will be very helpful to my headache. > > > > Thank you. > > > > Best regards, > > > > Jungwook Chae > > > > Korea University in South Korea. > > > > The reason we started to use Java is historical. > First we came from a Java EE area, when Sun donated the filter to OOo, > but most of all the first XSLT processor, long time the best, was XT. XT > was the reference implementation of the W3C for XSLT 1.0. C++ was long > time not capable of XSLT the way XT was. > Nowadays we have a similar problem of XSLT2. > > Therefore we have to decide between performance and functionality and > for me the functionality wins. > With OOo 3 Saxon-B will be used as default XSLT processor in OOo. > > In the end I hope that we can use in the future extensions in OOo that > are capable to rely on other extensions. > By this it would be possible not to use even an XSLT filter as > extensions (since OOo 3.0), but as well an XSLT processor. > (Perhaps marking the extensions requirements by some RDF in the > configuration.)
Frankly, I like having the Java XSLT processors. I haven't looked closely at adding extensions to libxslt, other than a quick scan over http://xmlsoft.org/XSLT/extensions.html. However, we have a fairly easy way in OOo to add XSLT extensions with either Xalan or Saxon. For example, this is a way to approach handling base64 encoded binary image data. Secondly, I've used libxslt, both as part of XML Copy Editor and stand-alone to transform XML using the IBM developerWorks XML Author package (see http://www.ibm.com/developerworks/library/i-dwauthors/) and it is way slower than Xalan (or MSXML). I haven't researched whether this is some peculiarity of the dW stylesheet, but we're talking many minutes vs a few seconds here. On a 64-bit Fedora 9 system (Athlon 3500 +) I get: ]$ time /opt/ibm/java2-i386-50/bin/java org.apache.xalan.xslt.Process -IN index.xml -XSL ../xsl/5.10/dw-document-html-5.10.xsl -OUT index1.html real 0m4.034s user 0m3.580s sys 0m0.423s $ time xsltproc -o index2.html --timing ../xsl/5.10/dw-document-html-5.10.xsl index.xml Parsing stylesheet ../xsl/5.10/dw-document-html-5.10.xsl took 0 ms Parsing document index.xml took 1 ms Running stylesheet and saving result took 23 ms real 4m26.765s user 4m22.286s sys 0m0.160s The libxslt version runs for over 4 minutes at 98% CPU while the Xalan Java one is done in 4 seconds or so. I see similar discrepancies on 32-bit Linux system as well as 32-bit windows XP. I have no idea what libxslt thinks it is actually measuring to come up with its timing numbers but it isn't the same thing as the time command (or my wristwatch) is measuring. -- Ian Shields <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
