Hi Jungwook Chae,

It is always a good idea to come up with questions on the list, as
others might have similar feelings.
Therefore I replied to the xml list as you earlier wanted to do...

채정욱 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.)

Regards,
Svante


Reply via email to