You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agsoftware.dnsalias.com> on 2004/01/02 09:16:58 UTC
Saxon as the default XSLT procesor
Hi:
2 recently threads make me think about the topic of the thread. AFAIK
Cocoon does not try to stick on any product but Jetty performs better than
Tomcat:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107213647015861&w=2
another fact is Saxon better than Xalan:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107243671502545&w=2
JETTY:
======
The license is compatible with Apache since we are already distributing a
small version of jetty inside Cocoon.
SAXON:
======
Saxon is Mozilla Public License 1.0. It is an OSI aproved license too. But
I am not sure if it is compatible with ASF license:
http://www.opensource.org/licenses/mozilla1.0.php
Question:
If the MPL 1.0 is ASF compatible then can we include Saxon as part of
Cocoon? AFAIK it will deliver better performance that for sure all the
users will welcome.
I understand that Cocoon project is not sticking on any 3rd party product
from another project, but I think is very important enhance the user
experience by default to the best products we can use in each area. This
is why I made a similar question somedays ago about the default XSP
compiler:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107194493701061&w=2
I appreaciate the replies from Vadim and Stefano about my request of
changing the XSP compiler topic. They helps me understand that eclipse
compiler was the currently best choice right now.
Please note I am not requesting to remove Xalan nor close the door to
Xalan. I am just requesting to include Saxon since it performs better and
seems to have less bugs.
WDYT?
Best Regards,
Antonio Gallardo
Re: Saxon as the default XSLT procesor
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Nicola Ken Barozzi wrote:
>> document() calls in the style sheet,
>
> There are. I'm gonna remove them soon, nut for now they are there, and
> will the possibility to use them will remain some time for backward compat.
>
>> because at least in the Cocoon releases I used it gets passed
>> null as Source quite often for no obvious reason.
>
> Wierd...
>
I think it's a Cocoon bug. The first invocation of the pipeline is ok,
but in followup incovations the XSLT processor often gets a null
SourceResolver (not Source, sorry). Xalan uses its own URIResolver in
this case, while Saxon (6.x series) takes it literally. That's one
of the dark corners of the TrAX spec, I couldn't find any regulations
guiding the behaviour.
The null is not a MT problem, it happens even for low load. I think
it has something to do with incorrect re-initialization of the pipeline
after the SourceResolver has been recycled and the reference had been
nulled.
Given the added problem that document() referenced stuff doesn't influence
cache validity, I switched to aggregation. If the document() gets the
URI from source XML, this can be painful (XSLT to an XInclude source,
then Xinclude, the the final XSLT instead of just one XSLT). The worst
thing is that you can't easily test the XSLT any longer with command
line tools, even though none of the dynamic features (like cocoon: URIS)
are used. If you've to ftp the damn sources to the app server, this really
slows down development :-/ .
J.Pietschmann
Re: Saxon as the default XSLT procesor
Posted by Nicola Ken Barozzi <ni...@apache.org>.
J.Pietschmann wrote:
> Nicola Ken Barozzi wrote:
>
>> But... I swapped Xalan with Saxon 6.5.3 in Forrest and I get a NPE :-(
>
> That's not unusual. Did you use the most recent Cocoon?
Almost. It's some quite recent dev version.
> I suppose there are no document() calls in the style sheet,
There are. I'm gonna remove them soon, nut for now they are there, and
will the possibility to use them will remain some time for backward compat.
> because at least in the Cocoon releases I used it gets passed
> null as Source quite often for no obvious reason. Xalan tends
> to ignore this, while Saxon barfs.
Wierd...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Saxon as the default XSLT procesor
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Nicola Ken Barozzi wrote:
> But... I swapped Xalan with Saxon 6.5.3 in Forrest and I get a NPE :-(
That's not unusual. Did you use the most recent Cocoon?
I suppose there are no document() calls in the style sheet,
because at least in the Cocoon releases I used it gets passed
null as Source quite often for no obvious reason. Xalan tends
to ignore this, while Saxon barfs.
J.Pietschmann
Re: Saxon as the default XSLT procesor
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
...
> I've done some tests on my machine using the XSLTBench and here is what
> I got:
>
> Saxon 6.5.3 -----> 49.52
> XalanJ 2.5.2 ----> 19.89
>
> couldn't test XSLTC
>
> So, +1 to change to Saxon.
I'm +1 to change to anything compatible that is faster than Xalan.
But... I swapped Xalan with Saxon 6.5.3 in Forrest and I get a NPE :-(
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Saxon as the default XSLT procesor
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Tim Larson dijo:
> --- Antonio Gallardo <ag...@agsoftware.dnsalias.com> wrote:
>> Timothy Larson dijo:
>> > Here is the message from Michael Kay:
>> > http://sourceforge.net/mailarchive/forum.php?thread_id=3618018&forum_id=1398
>>
>> Hmm. I can't open the link. :(
>
> I opened it from two computers on different networks (work and home).
> Perhaps it wrapped in your mail reader, or your mail reader acts like
> one I stopped using that silently drops part of the query parameters.
> Could/did you try manually copying and pasting the URL into the browser?
Hi:
Interesting enough. Now I can open it. Before it send me a page telling
there is no post. ??? OK. Thanks for the link.
Re: Saxon as the default XSLT procesor
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Timothy Larson dijo:
> --- Robert Koberg <ro...@koberg.com> wrote:
>> Corporate sponsorship has been pulled from Saxon too (Kay was employed
>> by Software AG). He recently left. He said on the saxon list that he
>> will continue to support it, though most effort will go into v7+.
>>
>> He also mentioned he might release a commercial version...
>>
>> -Rob
>
> Here is the message from Michael Kay:
> http://sourceforge.net/mailarchive/forum.php?thread_id=3618018&forum_id=1398
Hmm. I can't open the link. :(
Best Regards,
Antonio Gallardo
Re: Saxon as the default XSLT procesor
Posted by Timothy Larson <ti...@yahoo.com>.
--- Robert Koberg <ro...@koberg.com> wrote:
> Corporate sponsorship has been pulled from Saxon too (Kay was employed
> by Software AG). He recently left. He said on the saxon list that he
> will continue to support it, though most effort will go into v7+.
>
> He also mentioned he might release a commercial version...
>
> -Rob
Here is the message from Michael Kay:
http://sourceforge.net/mailarchive/forum.php?thread_id=3618018&forum_id=1398
--Tim Larson
__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003
Re: Saxon as the default XSLT procesor
Posted by Robert Koberg <ro...@koberg.com>.
Stefano Mazzocchi wrote:
>
> On 2 Jan 2004, at 09:16, Antonio Gallardo wrote:
>
>> Hi:
>>
>> 2 recently threads make me think about the topic of the thread. AFAIK
>> Cocoon does not try to stick on any product but Jetty performs better
>> than
>> Tomcat:
>>
>> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107213647015861&w=2
>> another fact is Saxon better than Xalan:
>> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107243671502545&w=2
>>
>> JETTY:
>> ======
>> The license is compatible with Apache since we are already distributing a
>> small version of jetty inside Cocoon.
>>
>> SAXON:
>> ======
>> Saxon is Mozilla Public License 1.0. It is an OSI aproved license too.
>> But
>> I am not sure if it is compatible with ASF license:
>> http://www.opensource.org/licenses/mozilla1.0.php
>>
>> Question:
>>
>> If the MPL 1.0 is ASF compatible then can we include Saxon as part of
>> Cocoon?
>
>
> Yes. It is.
>
>> AFAIK it will deliver better performance that for sure all the
>> users will welcome.
>
>
> Yep, nobody complains about better performance.
>
>> I understand that Cocoon project is not sticking on any 3rd party product
>> from another project, but I think is very important enhance the user
>> experience by default to the best products we can use in each area. This
>> is why I made a similar question somedays ago about the default XSP
>> compiler:
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107194493701061&w=2
>>
>> I appreaciate the replies from Vadim and Stefano about my request of
>> changing the XSP compiler topic. They helps me understand that eclipse
>> compiler was the currently best choice right now.
>>
>> Please note I am not requesting to remove Xalan nor close the door to
>> Xalan. I am just requesting to include Saxon since it performs better and
>> seems to have less bugs.
>
>
> I think Xalan is one example of a community that would die overnight if
> the corporate sponsor pulled the plug.
Corporate sponsorship has been pulled from Saxon too (Kay was employed
by Software AG). He recently left. He said on the saxon list that he
will continue to support it, though most effort will go into v7+.
He also mentioned he might release a commercial version...
-Rob
> It might be said the same about
> Saxon since it's a one man show, but knowing Xalan a little, I think
> Saxon would be easier as a codebase to patch if Mike Kay decided to quit
> (or got hit by a bus). [it's hard to think at something more complex
> than Xalan to work on]
>
> What I like about this move is the signal is gives: imagine the press
> "Cocoon moves away from its own Xalan and uses Saxon". Xalan has been
> languishing and there is no community, the codebase is incredibly
> complex (yet not the most performant, which irritates me) and translets
> (which were a super-nice idea) are still left behind.
>
> I've done some tests on my machine using the XSLTBench and here is what
> I got:
>
> Saxon 6.5.3 -----> 49.52
> XalanJ 2.5.2 ----> 19.89
>
> couldn't test XSLTC
>
> So, +1 to change to Saxon.
>
> --
> Stefano.
>
Re: Saxon as the default XSLT procesor
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
<snip/>
> I've done some tests on my machine using the XSLTBench and here is
> what I got:
>
> Saxon 6.5.3 -----> 49.52
> XalanJ 2.5.2 ----> 19.89
>
> couldn't test XSLTC
There's also JD at http://www.aztecrider.com about one year ago: it had
impressive performances (way faster than Saxon) but bugs in its
serialization part.
Unfortunately, it appears to be no more opensource since the end of last
year...
Does anybody have the latest opensource version of the JD XML tools
(released in october 2003)? If yes, please let me know either publicly
or privately. I'm interested in them, as the architecture is even
simpler than Saxon.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Saxon as the default XSLT procesor
Posted by Stefano Mazzocchi <st...@apache.org>.
On 2 Jan 2004, at 09:16, Antonio Gallardo wrote:
> Hi:
>
> 2 recently threads make me think about the topic of the thread. AFAIK
> Cocoon does not try to stick on any product but Jetty performs better
> than
> Tomcat:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107213647015861&w=2
> another fact is Saxon better than Xalan:
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107243671502545&w=2
>
> JETTY:
> ======
> The license is compatible with Apache since we are already
> distributing a
> small version of jetty inside Cocoon.
>
> SAXON:
> ======
> Saxon is Mozilla Public License 1.0. It is an OSI aproved license too.
> But
> I am not sure if it is compatible with ASF license:
> http://www.opensource.org/licenses/mozilla1.0.php
>
> Question:
>
> If the MPL 1.0 is ASF compatible then can we include Saxon as part of
> Cocoon?
Yes. It is.
> AFAIK it will deliver better performance that for sure all the
> users will welcome.
Yep, nobody complains about better performance.
> I understand that Cocoon project is not sticking on any 3rd party
> product
> from another project, but I think is very important enhance the user
> experience by default to the best products we can use in each area.
> This
> is why I made a similar question somedays ago about the default XSP
> compiler:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107194493701061&w=2
>
> I appreaciate the replies from Vadim and Stefano about my request of
> changing the XSP compiler topic. They helps me understand that eclipse
> compiler was the currently best choice right now.
>
> Please note I am not requesting to remove Xalan nor close the door to
> Xalan. I am just requesting to include Saxon since it performs better
> and
> seems to have less bugs.
I think Xalan is one example of a community that would die overnight if
the corporate sponsor pulled the plug. It might be said the same about
Saxon since it's a one man show, but knowing Xalan a little, I think
Saxon would be easier as a codebase to patch if Mike Kay decided to
quit (or got hit by a bus). [it's hard to think at something more
complex than Xalan to work on]
What I like about this move is the signal is gives: imagine the press
"Cocoon moves away from its own Xalan and uses Saxon". Xalan has been
languishing and there is no community, the codebase is incredibly
complex (yet not the most performant, which irritates me) and translets
(which were a super-nice idea) are still left behind.
I've done some tests on my machine using the XSLTBench and here is what
I got:
Saxon 6.5.3 -----> 49.52
XalanJ 2.5.2 ----> 19.89
couldn't test XSLTC
So, +1 to change to Saxon.
--
Stefano.