XSLT2 Is Useful
Listen, I really appreciate the work Microsoft has done on IE8 standards, and I think LINQ to XML really improves on the W3C XML DOM, but I also need to produce XML from templates.
You see, ASP.NET really only produces HTML from templates. If you want to produce RSS, Atom, POX, SVG, P3P, XSLT, or XSL-FO from templates, probably the best way to do this (for flexibility, maintainability, and readability) is with XSLT Simplified Syntax.
<content type="xhtml" xml:lang="en">
This is more readable and maintainable than using the DOM to build up the document, or a full XSLT stylesheet. It is much more approachable, since it is a simple template, which allows trivial changes without having to understand the complete XSLT syntax. Plus, a minimal .NET HTTP handler can apply XSLT to source XML (perhaps produced by SQL Server) without much code to maintain.
Anyone that's tried to use XSLT 1.0 quickly finds that they can't use most of the modern methods they've become used to in other languages: regular expressions, date/time/number parsing and formatting, grouping, data structures, Unicode support, date/time/timezone/duration data types and functions, set manipulation, aggregate functions, and converting relative URLs to absolute ones, to name some common examples of things that are simply prohibitively difficult and complex in XSLT 1.0 (particularly using the simplified syntax).
Of course these have all been addressed in XSLT 2.0 and XPath 2.0, released as W3C Recommendations over a year ago, moving XSLT from curiosity to practical templating engine.
The .NET XSLT library still only supports XSLT 1.0 and XPath 1.0.
The emphasized functions in the above example give an indication of why this is a problem. How can you provide aggregate functions and date/time formatting without those functions without losing the benefits of the XSLT Simplified Syntax? There are really only two practical answers.
Buy Saxon (or use Saxon Basic, which is free).
- You support Michael Kay, XSLT ninja.
- The market for XSLT grows.
- You won't have to make changes to all of your templates when Microsoft finally supports XSLT2.
- You spend no time trying to figure out how to work around the lack of a simple XSLT2 feature.
- You get used to XSLT2.
If your needs are more modest, you could try converting your stylesheet to XSLT1 and work around the limitations of that implementation.
- You don't spend time learning a third party library.
- You don't have to manage a third party library when deploying your system.
- You spend no money, provided you do not assign any value to the time required for you to come up with workarounds.
Obviously, you only want to use this approach if you have to, or if there are only a few simple workarounds to get what you want into the template, such as using the SQL Server CONVERT function to format date/time/currency/numeric values before building the XML document, or altering the XML DOM to add or substitute formatted or aggregate values before applying the stylesheet.
Microsoft really needs to focus some resources on getting XSLT 2.0 into the next release of .NET. Clearly, between IE8 and OOXML, standards support is on Microsoft's TODO list, and there's no question about their committment to XML. Microsoft even knows that their customers want XSLT2. The only question that remains is when market pressure will intensify the need to implement this omission. Be sure to contact Microsoft's XML Team to request a timeline for XSLT2.