Bernhard Zwischenbrugger wrote:
> I think it isn't a secret that
> lots of people unsubscibed from
> sablotron list because of the
> release of libxslt 1.0.
> (http://xmlsoft.org/XSLT/)
This is definitely not true. People are subscribing and unsubscribing
all the time, but a lot of people sent their "unsubscribe" directly to
the list recently. This is why it looks like everybody is hurrying out.
The overall number list members (about 300 currently) is slowly growing
in a long term.
> Maybe it is a good time to compare
> this 2 products now.
>
> I was using sablotron for about half a year
> und was really happy to have this
> xslt processor.
>
> At the moment am thinking about a change
> to libxslt but don't know the big
> differences.
Let's try to compare some differences. (Matt, please let me know if I'm
wrong in any point)
Sablotron
1. parser: expat (small (RPM 280 kB) one purpose XML parser, fast
reliable)
2. size: RPM about 400kB
I do not compare src size as libxslt tarball contains a lot of stuff
such as tests and docs. Sablot is bigger than libxslt since it
implements e.g. DOM which is (intentionally) missing in expat, while
libxslt is pure XSLT library.
3. portability: good (we do test on a lot of platforms, reported bugs
are fixed)
4. features: still some missing
5. speed: fast (in spite of XSLT Mark)
6. development pace: slower
GA doesn't spent investors money and we can spent on Sablotron just as
much as we can earn. However, a help of independent contributors and a
support from other companies make us optimistic about the future. Also,
we can now afford to dedicate more manpower to Sablotron than a half
year ago. One of our new guys already works on Sablot.
7. license: MPL/GPL
MPL is slightly more permissive to companies willing to link the code.
For some of them it even makes a difference.
libxslt
1. parser: libxml (bigger (RPM 770 kB) multi-purpose XML toolkit, fast
reliable)
2. size: RPM about 220 kB
3. portability: good
4. features: complete
5. speed: faster (according to XSLT Mark)
6. development pace: fast (Daniel is experienced enough in XML and no
doubts he's an excellent programmer. His work was supported by RedHat
and he seems to be really focused on it.)
7. license: LGPL
I'm sure I have missed some important issues :)
> I have seen that sablotron is faster than
> libxslt but does not provid all the
> features xslt 1.0 has defined.
>
> It's good to have 2 products to choose one
> of them. At the moment I don't really know
> how to deside which of these products fits
> better to the things I am going to do with
> them.
Sablotron claims to be a small footprint and portable processor from the
beginning. We will continue in this way; main missing features should be
implemented in terms of months (xsl:number, xsl:import and key() are in
progress).
libxslt is simply a great tool and it shall definitely have (and already
has) tuns of users. My feeling is that libxslt shall be a kind
mainstream while Sablot a kind of alternative, but I don't know the
future (nor even Daniel's plans and intentions.
The decision which one to use seems to be a bit personal. I will still
use Sablot for my personal work (otherwise I would have hard times in GA
:)
> Maybe someone from gingerall can talk
> a little about the future plans of sablotron.
We have implemented the DOM interface subset (including the Perl
support) recently, one even more interesting feature is planned in the
near feature (sorry, but can't say more currently as this project is
commercially supported; however its results will be available).
The next big challenge is the support of user defined functions, user
scripting etc. We're experienced with the use of Mozilla JavaScript
engine and its integration into Perl and/or C programs. We will work on
optimizations and performance improvements in the same time.
So in other words, we will try to turn Sablotron to a light-weight XML
toolkit (XSLT, DOM, XPath, extensions) while keeping its portability and
fastness. I'm sure there will always be some features missing in libxslt
and vice versa and two products give you more choice than just one.
> I hope you see this as a positiv critic.
Not even a critic. Good questions.
Greetings from rainy Prague
Petr
> greetings from vienna
>
> Bernhard Zwischenbrugger
> http://datenkueche.com
--
Petr Cimprich
Ginger Alliance
www.gingerall.com
