Re: Is Saxon the *only* XSLT 2.0 engine?

>    Michael> There are two others, Colin Adams' Gestalt XSLT, and
>    Michael> Altova's XSLT 2.0 processor.
>
>    Michael> Saxon, of course, is the best.
>
> Well, I can't let that go unchallenged.
>
> If you want to write interactive scripts which invoke an XSLT 2.0
> processor, then Saxon is a poor choice, as it's dependence upon the
> Java VM means it is too slow for interactive use (*).
> If you want to serialize to a web service, or other HTTP server, then
> it is of no use at all to you, as HTTP writes don't work (*).
> If you want to invoke XSLT 2.0 programmatically from a good
> programming language (i.e. Eiffel), then it is far too difficult to
> use Saxon (.NET version excepted, I guess).

Hmmm....

The moment Saxon 8.7N (for dotNet) was announced I decided to write as
a fun exercise an XPath 2.0 Visualizer. This was basically done just
in a few hours with some tuning around in the next couple of days. The
programming language/environment is C#/.NET1.1

The XPath Visualizer 2.0 uses Saxon 8.7N. Alternatively, it can use
any other XSLT processor, which allows the source xml to be (.Net 1.1)
an XmlReader and the stylesheet to be an (.Net 1.1) XmlNodeReader.

As we all probably know, an XPath visualizer is a highly interactive
program. I have been playing with it for a while and haven't noticed
any tangible delays, the response time is very suitable for a good
interactive experience. A noticeable small delay is experienced only
for the evaluation of the very first XPath expression in a user
session.

Some problems so far were the way an error message for an XPath
expression reports the source (line number) of the error.

Needless to say, I also have in mind other interactive XSLT2.0 based
applications in C#/.NET and I will be very happy to see more XSLT 2.0
processors for this programming environment.

--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.