Thought on Microsoft client XQuery

I've known for a couple of weeks now that XQuery and the new XML-SQL client mapping have been dropped from System.Xml in .NET 2.0. The XQuery implementation over the XML data type in SQL Server 2005 is NOT going away, of course. Just the client-side bits. Folks are encouraged to keep using XSLT 1.0 and XPath 1.0 on the client for a while. Hmmm…

After reading (more than twice) through all of the reasons for this decision, the one that makes the most sense to me is the product schedules. The reason that doesn't quite ring true to me is "folks are happy with the XML DOM". I can't help thinking that folks were quite happy doing everything through cursors in the early days of SQL because they didn't quite grok where the power of the relational model was yet. SQL cursors were "comfortable", as the XMLDOM is to XML programmers today. The schedule argument is more reasonable. If XQuery spec won't be "done" until next year, there is hesitation about producing an implementation based on an "in progress" spec that could change at the last minute. If you remember XSL Patterns and XDR schemas in Microsoft APIs you'll understand why. But…

This week at Win-Dev folks "across the hall" were lecturing in earnest about the WSE 2.0 offering. The WSE (web service extension) offerings are supported add-ons, outside of the "core" .NET APIs, and mostly implementations of various WS-* specs-in-progress. They're not guarenteed to be compatible with future offerings or with Indigo, the next generation WS-*++ implementation. In fact, some of the specs that were supported in WSE 1.0 have already completely vanished from the WS-* landscape. There's *way* more churn in this space.

Got me thinking…why not a similar model for XQuery? That is, a supported add-on implementation of the current specification with namespaces that begin with Microsoft.* rather than System.Xml.*. Guarenteed to change, at least subtly, but existing to get folks used to using it. The alternatives, that is, using Saxon.NET or working on a community implementation of XSLT 2.0/XQuery 1.0/XPath 2.0 are already happening. How about it…Microsoft.Xml.Query/Microsoft.Xml.Mapping anyone?

2 thoughts on “Thought on Microsoft client XQuery

  1. I think the problem is the schedule of Visual Studio and .NET Framework releases. They are few and far between. Now, this is not generally bad (I shudder to think of Java multitude of incompatible releases) but it clashes with other technologies’ release schedules, in this case XQuery.
    If it’s not ready, please don’t ship it. Some people will continue to produce software that uses XDR and similar technologies for years to come – they don’t care that there is a standard now, as long as XDR is supported on MS platforms. I don’t want another technology to encourage these kind of people.
    You say there are community products that will fill this void. Fine by me – I want MS to release it’s own implementation once the technology is standardized. Note also that MS has been criticized many times for not waiting for standards and being early. A move like this bodes well for MS IMHO.

  2. I am completely for Microsoft.*.XQuery. I was excited about it until MS dropped it from the next major release. As for Drazen’s comment, I think having it in Microsoft.* namespace makes it "non-standard" implementation and people who are looking for a "standard" implementation then, obviously should not use it. But it will definitely get people used to XQuery and I for one, really am looking to play with it because XSLT/XPATH combo seriously makes things difficult for me oftentimes.

Comments are closed.

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.