Mike Champion recently summarized quite nicely why we are not including XQuery support in the Whidbey version of the .Net Framework. However, some people are now wondering why some of these arguments do not apply to the SQL Server server-side implementation. For example, Oleg writes:
What I still dislike is the lack of a consistency. A subset of XQuery (which is considered as stable enough) is still going to be supported in SQL Server 2005, but not in .NET. Weird, but you know, admit it - SQL Server team just can afford it.
Affordability is not the main reason. So let me give you the top 3 reasons why we think that we can and should ship a limited XQuery support inside the database engine:
- SQL Server (unlike the .Net Framework) already has mechanisms to deal with future changes that break backwards-compatibility (the database compatibility levels). Thus, if we implement something that is not according to the final standard either on purpose or the standard changes after we ship, we can provide a way to users to chose the compatibility level, when we align the behaviour with the standard in a future release. The .Net Framework has no such capability and would make a revision much harder on the programmers.
- Since we are planning on using XQuery to query XML data, we did not want to provide a stop-gag language such as XPath 1.0. That would have cost us almost as much in implementation cost and would have created instant legacy. And not providing a query language on the XML would not be very useful, wouldn't it? OTOH, the .Net Framework already provides such languages and has to carry them forward in any case.
- By scoping the XQuery implementation to a subset, we minimize the risk of non-anticipated breaking changes while still providing values to our customers. It also allows us to grow our implementation into what users really need in XQuery instead of wasting resources in implementing/testing and documenting functionality that is rarely used. And yes, I know that we currently do not implement some useful functionality such as user-defined functions and modules (which are still being worked on in the working group).