I want to thank to everybody who took part in this interesting
discussion (overslept by me in my geographic location).

The results of this discussion are clear to me: it would be
inefficient to run an xslt processor as a background process and
pipiline the results by capturing them.

More than inefficient, it would be dangerous to run an XSLT processor
as part of a *generally available* web service (I can only smile
envisioning the kinds of creative DOS attacks that would be possible).

Lastly, as a spoilt Windows desktop user who has an excellent
(although XSLT 1.0) IDE with a one or two - click capability to run
any of 10 different XSLT processors, including Saxon 8.x and
Saxon.NET, I would never use any command-line in the background or any
ws beast.

When Saxon.NET is released it will accept as input the  .NET
System.XML XMLDocument, XPathDocument,... etc. and again will be able
to produce as output native .NET objects, which is  the main fact
justifying the ".NET" in its name.

Better than this will be only an XSLT 2.0 processor written in and for
the .NET platform (e.g. written in C#).


Cheers,
Dimitre Novatchev.

On 6/2/05, Karl Stubsjoen <kstubs@xxxxxxxxx> wrote:
> All right, is saxon available for windows?  Is it free, or requires
> licensing for a commercial application?  Is there a window objecty
> model to extend use of Saxon to VB and .Net applications?
>
> Thanks... might be time to swith parsers!