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:
These data points left us two real conclusions:
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 :)