December 07, 2005

Clarifications Regarding .NET 2.0, NXSLT 2.0, and XSLT 2.0

With as much time as I have and continue to spend around the .NET platform (v1.1 and v2.0) as well as around XSLT(v1.0 and v2.0) it easy for me to make distinctions between what versions of .NET and XSLT other products that implement and/or extend these technologies support. However, it recently occured to me that others who don't spend as much time around these technologies may be a bit confused by what supports what and why things can't be a little less confusing in this regard.

For the record, I thought I would quickly provide clarification as to how all three of the subject line products/specifications relate to one another.

* .NET 2.0 and XSLT 2.0 support
The .NET 2.0 Framework Class Libraries, as of yet, do not contain support for XSLT 2.0. It does seem like this will change, but no official announcements have been made nor have the hints that support is in either in-progress or will be relatively soon contain any sort of date as to when this will become available. At the moment Saxon.NET(one of the projects I develop) and Altova(using as .NET wrapper of their COM-based XSLT 2.0 processor) are the only two products that support XSLT 2.0 transformations inside of a .NET 2.0-based application using C#, VB.NET, or any other language that allows the ability to reference .NET 1.1 or 2.0 assemblies within the confines of its implementation.

* XSLT 2.0 and NXSLT 2.0
With this in mind, at present time NXSLT 2.0, which has a primary focus towards enabling .NET 2.0-based XSL-Transformations via the command line, does not support much of the XSLT 2.0-based features. However, Oleg has gone to great length to begin to bring several XSLT 2.0 features, such as support for multiple output, within the confines of this fantastic tool. While I would hate to suggest that there is any downside to this(how could you possibly complain when someone provides more features than are currently available... FOR FREE!!!) there is a possibilty that because of the one letter difference between the two names [XSLT 2.0 | NXSLT 2.0], those who do not spend their life eating, breathing, and from every conceivable angle, obsessing themselves with the .NET platform and XSLT 1.0/2.0, may find themselves a bit confused by the one letter that seperates these two from being equal.

NOTE: I suddenly just realized that it would be a REALLY good idea for me to contact Oleg and discuss the possibility of integration support for Saxon.NET into his NXSLT 2.0 command line tool. Beyond the fact that it would be REALLY COOL, this would also help alleviate the potential confusion by providing native support for the XSLT 2.0-Basic spec. While I have enough experience with these kinds of things to know that things are not always as easy as they might sound, it would seem to me that a quick check of the version(the namespace stays the same and as such can not be used to determine what version of XSLT is contained within) contained in the xsl:stylesheet element[1] should do the trick. The other possibility would be to create a command line switch if theres no way to check the version without causing a slow down in the processing. Why would this slow things down? Well, to check the version you would have to load the stylesheet into an XMLDocument-based type -- Its possible that the new XslCompiledTransform class might expose this information, but then again given that as a stylesheet is being loaded(at least I assume this to be the case... Looks like Mr. Lutz Reoder will be paid a visit here in a sec to verify this ;) it checks to see whether or not the version identifier is something it understands, and if not, it should throw an exception and as such that information wouldn't be avaialable given that the stylesheet never finished loading in the first place -- or wait -- maybe thats how you would do it -- catch the exception and try loading it into a Saxon.NET XMLDocument type -- hmmm... that should work...

Well, anyway(sorry for the "walk in the park with my thought process" interlude there... ;), I think an email to Oleg is in due order... If something becomes of this I will let you know.

Enjoy your "NXSLT 2.0 with XSLT 1.0, EXSLT, and some extended XSLT 2.0-like support" enhanced day!

---
[1] : or the xsl:transform element which is once again a part of XSLT via the 2.0 spec and can be used as a synonym for xsl:stylesheet -- if for no other reason(and there are LOTS of other reasons)... THANK YOU Dr. Kay and W3C XSLT working group for this one WONDERFUL reinclusion into the spec :)