Re: JAXTHelper vs LibXSLTTransformer, which one is preferred?
On Thu, 2012-09-06 at 10:19 +0200, David Tardon wrote: > Hi, > > On Wed, Sep 05, 2012 at 03:18:36PM +0200, Peter Jentsch wrote: > > Splitting the Saxon stuff should be possible and has been one of the goals > > of the libxslt port. I haven't tested that, though. > > I tried to do the first step--building the java transformer as an > extension--a couple of weeks ago ... I am going to give it > another try soon. ah!, shiny. That saxon really bugs me as it's an out of date version, but later versions can't be used because they miss the required features. > Anyway, I think there are going to be code changes needed. Some problems > that need to be addressed: the XSLT filter configuration dialog allows > to say that the java transformer should be used. But what if it is not > available? (Disable the config. item? But the filter will not work...) > What if it _had been_ available and was uninstalled later? (Revert to > the default transformer and let the filter just bail out with an error > if used? Or disable the filter--if that is even possible with the > current API?) Disable the config, revert to default if custom is unavailable throw an error dialog up with the link to the extensions page for the split off extension I suppose. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JAXTHelper vs LibXSLTTransformer, which one is preferred?
Hi, On Wed, Sep 05, 2012 at 03:18:36PM +0200, Peter Jentsch wrote: > Splitting the Saxon stuff should be possible and has been one of the goals of > the libxslt port. I haven't tested that, though. I tried to do the first step--building the java transformer as an extension--a couple of weeks ago, but stopped when I could not get it registered by the pkg manager (I had better/more interesting things to do at the time, so I did not try very hard :-) I am going to give it another try soon. Or I can send the patch to you and forget all about it (that would be my preferred solution :-) Anyway, I think there are going to be code changes needed. Some problems that need to be addressed: the XSLT filter configuration dialog allows to say that the java transformer should be used. But what if it is not available? (Disable the config. item? But the filter will not work...) What if it _had been_ available and was uninstalled later? (Revert to the default transformer and let the filter just bail out with an error if used? Or disable the filter--if that is even possible with the current API?) D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JAXTHelper vs LibXSLTTransformer, which one is preferred?
Splitting the Saxon stuff should be possible and has been one of the goals of the libxslt port. I haven't tested that, though. Peter Von meinem iPhone gesendet Am 05.09.2012 um 14:27 schrieb Caolán McNamara : > On Wed, 2012-09-05 at 08:15 +0200, Peter Jentsch wrote: >> JAXTHelper is not going away in the near future, as it provides support >> for XSLT 2.0, which is not going to appear in libxslt any time soon. > > Do any of our bundled xslt filter things make use of the JAXTHelper > stuff. I mean, "out of the box" is there anything we have that requires > the saxon-based stack ? I'm wondering about the theoretical possibility > of splitting that saxon-based stuff out as an optional standalone > extension that gets distributed from our extensions repository rather > than built-in. > > C. > > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JAXTHelper vs LibXSLTTransformer, which one is preferred?
On Wed, 2012-09-05 at 08:15 +0200, Peter Jentsch wrote: > JAXTHelper is not going away in the near future, as it provides support > for XSLT 2.0, which is not going to appear in libxslt any time soon. Do any of our bundled xslt filter things make use of the JAXTHelper stuff. I mean, "out of the box" is there anything we have that requires the saxon-based stack ? I'm wondering about the theoretical possibility of splitting that saxon-based stuff out as an optional standalone extension that gets distributed from our extensions repository rather than built-in. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JAXTHelper vs LibXSLTTransformer, which one is preferred?
Am 04.09.12 13:16, schrieb Caolán McNamara: > On Thu, 2012-08-30 at 10:10 +0900, mete0r wrote: >> Hi, >> >> I'm developing an document import filter (which will be packaged as >> an .oxt extension) and it needs to perform XSLT transformations during >> the process of importing (I don't believe xsltfilter could cover these >> process). So I'm finding a way to use XSLT transformation services >> directly. >> >> In libreoffice 3.5.4, which I'm working with, there seem 2 UNO service, >> i.e., com.sun.star.comp.JAXTHelper and >> com.sun.star.comp.documentconversion.LibXSLTTransformer. >> >> Currently I'm using the later one (by specifiying its service name in >> the ServiceManager.createInstanceWithContext()), but both are just >> working fine for me. So here are my questions: >> >> 1. Which one is preferred to be used in regard to forward/backward >> compatibility? It looks like LibXSLTTransformer is introduced later, >> then will JAXTHelper be deprecated at some point in the future? >> >> 2. Or should I choose one of them conditionally according to the version >> of the Libreoffice installation? If this is the case, from what version >> should I use LibXSLTTransformer? >> >> 3. Or direct instantiation and use of them like these (not through >> xsltfilter), is unsupported and discouraged way? >> >> Any guidance or comments would be greatly appreciated. > This isn't an area I know much about, maybe Peter can give the best > suggestions. But if the question ends up being "directly use the java > backend vs directly use the libxslt-based backend" then I imagine the > answer is to use the libxslt-based one. > > C. > > Hi mete0r, that's an interesting one: xslt filter uses LibXSLTTransformer as a default that can be overriden with JAXTHelper, but we don't have a real default for that. JAXTHelper is, as you said, the older implemenetation, and is the one still being used by Apache OpenOffice. It delegates transformation to a bundled version of Saxon 9 (Java). The main differences between the to services are as follows: LibXSLTTransformer: - fast initialization - does not require Java - supports XSLT 1.0 + most exslt extension (support for exslt within LibO depending on a patch pending to be submitted by me) - fast for most simple transformations - extensions need to be written in C an incorporated into LibO source (currently no dynamic loading of extension functions) JAXTHelper: - slow initialization - requires Java - supports XSLT 2.0 - contains some optimizations which make if a lot faster for some complex transformations - extensions need to be written in Java an can be bundled with LibO extensions (supports dynamic loading of extension functions) JAXTHelper is not going away in the near future, as it provides support for XSLT 2.0, which is not going to appear in libxslt any time soon. I'd suggest you choose on the criteria above, giving LibXSLTTransformer a slight preference. Cheers, Peter ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JAXTHelper vs LibXSLTTransformer, which one is preferred?
On Thu, 2012-08-30 at 10:10 +0900, mete0r wrote: > Hi, > > I'm developing an document import filter (which will be packaged as > an .oxt extension) and it needs to perform XSLT transformations during > the process of importing (I don't believe xsltfilter could cover these > process). So I'm finding a way to use XSLT transformation services > directly. > > In libreoffice 3.5.4, which I'm working with, there seem 2 UNO service, > i.e., com.sun.star.comp.JAXTHelper and > com.sun.star.comp.documentconversion.LibXSLTTransformer. > > Currently I'm using the later one (by specifiying its service name in > the ServiceManager.createInstanceWithContext()), but both are just > working fine for me. So here are my questions: > > 1. Which one is preferred to be used in regard to forward/backward > compatibility? It looks like LibXSLTTransformer is introduced later, > then will JAXTHelper be deprecated at some point in the future? > > 2. Or should I choose one of them conditionally according to the version > of the Libreoffice installation? If this is the case, from what version > should I use LibXSLTTransformer? > > 3. Or direct instantiation and use of them like these (not through > xsltfilter), is unsupported and discouraged way? > > Any guidance or comments would be greatly appreciated. This isn't an area I know much about, maybe Peter can give the best suggestions. But if the question ends up being "directly use the java backend vs directly use the libxslt-based backend" then I imagine the answer is to use the libxslt-based one. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
