Promises, promises
So much for for blogging more regularly. But if there was ever a reason to start up again, Mark's recent post on XSLT 2.0 and Dare's response are as good a reason as you can get. As the XML Query (XPath, XSLT, XQuery, anything else) Program Manager for the .NET Framework, it's time for me to chime in.
First, we're not abandoning XSLT 1.0. Far from it, we've completely rewritten our XSLT implementation from scratch in Whidbey (XsltCommand) in order to solve the major performance issues we had with the current implementation. Our original intention was to meet MSXML 4.0's incredible performance. I believe we'll surpass this goal by the time we release.
XSLT 1.0 will still be a (the?) core scenario for the query team, even in the Whidbey timerame. Transformation is a vital piece of functionality in most XML processing pipelines, this will not change in the forseeable future. The question then becomes, what is XSLT 2.0 bringing to the table that makes it compelling. We're not interested in implementing a standard just so we can tick off a checkbox on some feature list. We're here to solve customer problems.
Several years ago we sat down and evaluated the intentions of both XQuery 1.0 and XSLT 2.0 while they were both in their infancy. We looked at the pains our customers were telling us they were having. We looked at where we anticipated their pains would be in 5 or 10 years. This yielded some interested conclusions:
- People wanted a more powerful XPath...and all they had was XSLT. We saw (and still see) case after case of people who need some advanced querying functionality and shoehorning XSLT to solve the problem. XPath 2.0 doesn't solve the problem either because the scenarios required some XML construction in the results.
- XSLT syntax and programming paradigm is not user friendly. This was Mark's main point and is something we've heard from developers over and over again. Syntax is an easy problem to solve, just make a human-friendly alternative. However, the programming paradigm is quite hostile to anybody who isn't a fan of LISP. This is a fundamental issue many people have with the language.
- ASP.NET 2.0 is a phenomenal product. Many of us believe that one of our key XSLT scenarios, HTML generation, will be greatly diminished with the ease in which an ASP.NET solution can be developed. There will still be cases for XSLT on a web server, however this will be reduced in time.
These data points left us two real conclusions:
- Implement both XSLT 2.0 and XQuery in the .NET Framework
- Implement XQuery in the .NET Framework
There was much deliberation on this topic and we concluded that we were satisfying the transformation scenarios our customers had, but were failing on the core query scenarios. Given that we don't have infinite resources, we felt that having a strong XPath 1.0, XSLT 1.0, and XQuery 1.0 implementation was more important than having a mediocre XPath 1.0/2.0, XSLT 1.0/2.0, XQuery 1.0 story.
This is a bet that Microsoft is making. We're putting a stake in the ground and saying we want XQuery to be defacto XML query language. SQL Server 2005 will have a native XML datatype which will utilize XQuery. We're also talking with other product teams which use XML extensively to get them on the wagon. Again, this is to ensure that long term we have a strong, consistent message rather than a weak, fragmented one.
For those of you attending TechEd 2004 in San Diego this year, feel free to check out DAT327. Michael Rys and myself will be presenting a session on XQuery in SQL Server and the .NET Framework. You'll be able to grill us in person :)
