As I was catching up on email this afternoon, I noticed that Stylus Studio had sent out an XQuery-related newsletter which contained an interesting campaign to “save XQuery on Microsoft .NET 2.0”. As I read through the email, a few issues and questions arose for me which I felt would be best addressed by one of my famously, non-frequent blog posts.

Issue:  The basic premise of this petition is to convince Microsoft to ship XQuery as part of.NET Framework 2.0.
We have been in feature freeze for the .NET Framework quite some time now.  Heck, we recently released Visual Studio 2005 Beta 2, which includes .NET Framework 2.0 Beta 2, and are well on our way to RTM.  There’s no throwing features like XQuery in at this point in time, sorry.  If you’d like to know why we made the decision to cut this functionality, we posted our reasoning online several months ago.

Issue (this one's a minor nitpick):  The email states that the “.NET Frameworks ship only every 3 or so years”.
Hmm, let’s see:

  • Version 1.0 shipped as a part of Visual Studio .NET 2001
  • Version 1.1 shipped in Visual Studio .NET 2003 and Windows 2003
  • Version 2.0 will be shipping as a part of Visual Studio .NET 2005 and SQL Server 2005

The .NET Framework will also ship as a free, standalone SDK and redistributable, just as it has in the past.
<marketing_plug>In addition, we will be releasing free “Express” versions of Visual Studio 2005 and SQL Server 2005.  See previous product links for details.</marketing_plug>

Question:  What’s so important about having XQuery in the .NET Framework?
One of the fundamental design points of System.Xml was extensibility.  We decided well before we wrote our first line of C# that we needed to lay out an infrastructure that was extensible by everybody.  There’s no reason why somebody else can’t provide an implementation of XQuery which sits outside of the .NET Framework; and do it just as well as we can. (hint, some enterprising people are already working on this)

At the end of the day, we sat down and talked in depth to a lot of people about XQuery before we came to this decision.  On the .NET Framework, developers felt that XQuery added an unnecessary complication to an area which we should be focusing on the basics such as simplification and performance.  We took this feedback seriously and redoubled our efforts regarding general usability and performance (more on this in a future post or MSDN article).  On SQL Server, on the other hand, users felt that XQuery was an excellent fit for performing operations against the new native XML datatype available in SQL Server 2005.

I believe our current positioning shows that Microsoft is still commited to XQuery as a technology overall, but we’re not going to push it in areas where it doesn't provide a significant value-add over what's already available.  That said, we are obviously keeping an eye on people adopting XQuery both inside and outside SQL Server in order to help us plan for the future.

As always, feel free to post comments or email me directly: arpande at