Boy oh boy!
Mark Fussell sure earns the dinstinction of having posted one of the most controversial blog entries in a while on the topic of XQuery and XSLT.
As the Microsoft representative to the W3C XQuery Working Group and the Program Manager for the SQL Server Engine support of XQuery, let me join the fray.
Some good comments have been made in return to Mark's post, although some seem to have misunderstood Mark's point and some seem to clearly go off the deep-end. We are not killing XSLT 2.0 for some evil purpose, we just chose to not implement it for now. If enough other implementations will be done (I know Mike Kay is busy working on one), it will survive if it provides benefits. Both Dare and Arpan (welcome back to the world of Blogs, btw), have already given good clarifications here and here, that I would like to summarize here:
- We love XSLT for its template-based processing model that allows data-driven data transforms. But for most of these scenarios, XSLT 1.0 with EXSLT seem to address our customer needs (if not, I am sure Arpan and Mark want to hear from you) and XSLT 2.0 seems to provide little in addition (ok, the grouping and the extended function library can be useful).
- XQuery 1.0 is providing a language that addresses a different use case of formulating declarative queries over large amounts of XML in databases and caches. For this, XSLT is harder to program and manage and optimize in our opinion.
XPath 2.0 adds little value in itself if you have XQuery 1.0. The main differences are: no constructors, more axes (which I think should be available in a full-fledged XQuery implementation at some time anyway, except for the namespace axis), and XPath 1.0 backwards-compatibility mode. Heck, it even has a subset of the FLWOR expression (no let, no order by).
Regarding XPath 2.0, let me address some potential misunderstandings in Dare's posting (I confirmed this with him in person): When he referred to XPath 2.0, he meant XPath 2.0 with XPath 1.0 backwards-compatibility turned on. Also, he simplified the typing relationship. XQuery can be dynamically or statically typed and strong/weak typing is primarily a property of an individual type as XQuery and XPath both provide weakly and strongly typed data types (I will write another blog entry later this week that will go deeper into the XQuery and XPath type system).
Finally, the question about our (currently defunct) XQuery demo site. As Arpan explains, the demo code was not maintained anymore, so we decided to take it down since there are now two partial XQuery implementations available in (somewhat restricted) beta. I have argued that we provide at least a page at http://xqueryservices.com that provides the information about where to sign up for the .Net Framework beta. But so far, we did not get to it.
Your feedback is indeed appreciated. But you need to understand that the larger the software component gets, the more dependencies both in the code and in the organization itself needs to be managed. This overhead makes it much more difficult to whip up a complete implementation of something like XQuery and/or XSLT 2.0. Having a single person do everything in a small, well-defined component is actually in the short-term and often mid-term more efficient.