Microsoft XSLT Implementation

Oleg Tkachenko

I'm glad to announce version 1.2 of nxslt - .NET XSLT command line utility.

Changes since version 1.1: built-in support for 60 EXSLT extension functions, support for custom extension functions and some minor bug fixes

What is nxslt

nxslt is a small command line utility that allows to perform XSL Transformations (XSLT) using .NET Framework's XSLT implementation - System.Xml.Xsl.XslTransform class. nxslt basically dublicates functionality and command line options, provided by Microsoft's MSXSL.EXE Command Line Transformation Utility with small difference: unlike msxsl.exe, nxslt does not support specifying start mode. In addition, nxslt has some distinct advanced features, like support for embedded stylesheets, custom URI resolving, multiple result documents, custom extension functions, built-in rich library of EXSLT extenstion functions etc.

Requirements

nxslt is .NET Framework application, written in C# language and requires .NET Framework version 1.0 to be installed.

EXSLT support

nxslt supports rich library of 60 EXSLT extension functions [1], implemented by Dare Obasanjo, see his "EXSLT: Enhancing the Power of XSLT" article[2]. EXSLT support is enabled by default and cannot be disabled in this version. Full list of supported EXSLT functions is available at http://www.tkachenko.com/dotnet/nxslt.html#exslt-funclist

nxslt is freely available for download in precompiled Windows executable form and in source code (complete Microsoft Visual Studio .NET C# project): nxslt home: GotDotNet site gotdotnet.com

Jonathan Marsh

Please read the Microsoft documentation on what is supported, and in which release. Until complete XSLT support is available in all our products it is important to check the deployment details before making any assumptions about support. See http://msdn.microsoft.com/xml.

Marrowsoft support

Based on a question, list archive

The transformation engine will actually output either a UTF-16 string (BSTR) or a byte stream - where that stream might be text encoded as ASCII or a multitude of other encodings. ...

The output encoding is normally determined by the encoding attribute (if present) of the <xsl:output> element. If not specified, then the default in MSXML is always UTF-16.

But there is a big gotcha with this (and the cause of the biggest FAQ with MSXML) - in that even if the encoding attribute is specified, you may still end up with UTF-16 output depending on which methods you used to perform the transformation:-

1) if you use the .transformNode() method, then the output will always be UTF-16 because the result of that method is a BSTR - so it must, by nature, be encoded as UTF-16.

2) if you use the .transformNodeToObject() method then the output will be UTF-16 if the second parameter of that method call is a DOM object. But if the second parameter is a stream object (i.e. one that supports a .write() method) then the output will be encoded according to the encoding specified by the xsl:output encoding attribute

3) if you use the IXSLProcessor/IXSLTemplate interfaces to perform the transformation then it depends on 'how' you use these interfaces to determine whether you will get UTF-16 or some other encoding specified by the @encoding attribute. This is because the .output property of the IXSLProcessor interface can be set prior to transformation or just read after transformation. If the .output property is assigned prior to transformation with a stream object then the stream will be written to in the specified encoding. But if the .output property is only read after the transformation then the output will always be UTF-16 because the .output property, in this case, can only contain a BSTR.

If you don't know what the user is delivering to you to be transformed then it is probably best to use the IXSLProcessor/IXSLTemplate interfaces to perform the transformation - and set the .output property to a stream object prior to the transformation.