.net command line utility
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.
nxslt is .NET Framework application, written in C# language and requires .NET Framework version 1.0 to be installed.
nxslt supports rich library of 60 EXSLT extension functions , implemented by Dare Obasanjo, see his "EXSLT: Enhancing the Power of XSLT" article. 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
Which parts of XSLT and XPATH does Microsoft support
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.
Encoding issues using the Microsoft XSLT engine
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.