January 11, 2006

Microsoft and EXSLT - secret breakthrough

There are two new killer but undocumented features in Microsoft .NET 2.0 pertaining to EXSLT. Anybody like me regularly digging in System.Xml assembly probably knows it, but general audience is still unaware. So I want to share these secrets. ...

Secret #1. Unexpected surprise. Microsoft's new XSLT processor (XslCompiledTransform) supports natively two EXSLT extension functions - exsl:node-set() and exsl:object-type(). That is technically speaking XslCompiledTransform supports EXSLT - Common module.

Moreover, as mentioned in the "Introducing XslCompiledTransform" article on the Microsoft XML Team's WebLog, the behaviour of Microsoft specific msxsl:node-set() extension function is aligned with the behavior of the same function in MSXML and exsl:node-set() - when being given something other than RTF it returns text node containing string value of the passed object. As a matter of interest msxsl:node-set() and exsl:node-set() in XslCompiledTransform is the same function.

Now that means that XslCompiledTransform joins Saxon, Xalan, libxslt and other mainstream XSLT processors natively supporting exsl:node-set() function and any XSLT stylesheet using it for manipulating temporary trees is now completely portable between .NET 2.0, Java and other platforms. That's a substantial relief for anybody doing serious XSLT development. And that makes lots of practical sense to keep XML processing portable.

Secret #2. Using XSLT extension objects in .NET 2.0 now doesn't require FullTrust. MSDN documentation says opposite, but this is just a documentation copy-n-paste bug.

This used to be a showstopper problem for using EXSLT.NET in a semi-trusted environments like ASP.NET or ClickOnce and I was complaining about it all the way. Now this isn't a problem anymore and you can use EXSLT extension functions in ASP.NET applications, e.g. via my free eXml Web server control.

That doesn't mean of course that security is compromised in any way. Code Access Security is still in place and XSLT extension functions in .NET 2.0 can only perform what is allowed for the code that runs XSLT transformation. And as 70+ EXSLT.NET functions doesn't do anything dangerous like accessing file system or remote resources, it's safe to use EXSLT.NET functions in ASP.NET even on minimal trust level. Also don't forget that XSLT extension objects don't come with XSLT stylesheets - they must be passed in code explicitly so they are safe.

That's way cool. I only wonder why such killer features are not documented. I can only guess that this is probably a consequence of the poor Microsoft middle management problem - be these features documented no doubts they would be cut at early stage. Now that .NET 2.0 is out I urge everybody to use exsl:node-set() and exsl:object-type() functions along with eXml Web server control to make it impossible to cut these features anymore :)

We should thank Microsoft XML Team for making it possible even in undocumented way. And we should say thank you to Dare for pushing EXSLT inside Microsoft despite he thinks he didn't succeed:

I know this because I've been in that position trying to get us to implement EXSLT and Schematron when I was on the XML team. Did I succeed? The lack of any implementations of either technology from Microsoft shows I didn't even come close.

A good Microsoft Exchange server maintained by staff knowledgeable about Microsoft Exchange is a useful tool to some business that require worldwide access to email that Exchange 2007 hosting excels at, be it through self-hosting or Exchange email outsourcing outside the company.