Another interview with Michael Rys on Microsoft SQL Server 2005 and XQuery

Microsoft SQLXML is not SQL/XML, which is written with a slash. SQL/XML is the common name for part 14 of the official ANSI SQL 2003 standard, which defines an xml data type, operations on the xml data type, a set of xml publishing functions, mapping rules from relational to xml data, and so on. SQL Server 2005's new XML data type is based on this standard.

Hey, nice clarification. On XQuery support in SQL Server 2005:

So, we've chosen to focus on what is considered to be the more stable parts of the specification, which I believe address the majority of the use cases - I think that those who take advantage of SQL Server 2005's XQuery support functionality will reap the benefits that XQuery has to offer. Obviously, some customers will want more, but they should understand that we're committed to delivering more extensive support for XQuery over time as the XQuery specification becomes an official W3C recommendation.

That should be safe. So get prepared, because:

Currently, the plan is to ship Microsoft SQL Server 2005 sometime this summer though the exact date has not been publicly announced.

Now - the long awaited news - MSXML is back and kicking! I knew I'll happen.

As far as MSXML is concerned, we don't have a lot of requests for XQuery. And with Version 6.0, we think that MSXML will become the XML tools library for the native C and C++ code environment, and we'll continue to support it.

XQuery in SQL Server 2005 internals:

If you get down to the nuts and bolts of it, SQL Server's XQuery processing facilities rely on the underlying SQL query processor -- they're really quite integrated and there's no easy way to separate the two. But this actually brings up an interesting point about SQL Server's XQuery processor architecture - that under the hood, we're able to leverage our top-of-the-line relational query optimization engine technologies. As XQuery is a declarative language, we're able to do a pretty advanced job at decomposing and optimizing the underlying query. We've brought several innovations to this space to make optimization of XQuery expressions possible, and there is much more that can be done. [See Microsoft's recent SIGMOD 2004 and VLDB 2004 papers for more information - Ed.]

The papers are: "ORDPATHs: Insert-Friendly XML Node Labels" and "Indexing XML Data Stored in a Relational Database". ORDPATH is a hierarchical labeling scheme implemented in SQL Server 2005. Both articles are worth reading and contemplating.

And when it comes to XQuery support on client side - that's what I suspected:

If I was to summarize the state of XQuery support at Microsoft, I'd say that we think it's a great server-side technology for accessing large amounts of XML, its declarative nature makes it particularly well suited for optimization, and we support it 100%. On the client-side, we're still investigating here- we haven't seen our users crying out for declarative languages on the client side just yet.

Fair enough.

And finally really good news:

The XQuery working group - we're currently preparing a final last call, and there's light at the end of the tunnel. I see the process leading to a recommendation, probably in Q1 2006.

Now that sounds like a call for action. XQuery in SQL Server is soon to be here, so it's time to start learning and playing with this amazing technology. And that's what I'm gonna do.