Home > Learn XML > XML Tech Talks > Michael Rys on XQuery & SQL Server

An Interview with Michael Rys on XQuery, SQL Server 2005, and Microsoft XML Technologies

Dr. Michael Rys is the Program Manager for the SQL Server Engine Team at Microsoft. In this role, he has responsibility for many of the XML initiatives in Microsoft SQL Server, including the XQuery support in the upcoming SQL Server 2005, codenamed "Yukon"; Microsoft's server-side SQLXML technology; the XML Data type; and other XML related features being developed in Redmond. Dr. Rys also represents Microsoft on the W3C XQuery Working Group and has a seat on the SQL standardization committee at ANSI. Michael is co-author of "XQuery by the Experts", published by Addison Wesley, and he runs a very popular blog for Microsoft SQL Server XML enthusiasts.

Stylus Studio® is the leading XML IDE for XML data integration, featuring advanced support for XQuery development, including XQuery editing, mapping, debugging, and performance profiling, as well as tools for working with XML Schema and XSLT. Ivan Pedruzzi, Stylus Studio®'s Senior Product Architect and editor of The Stylus Scoop newsletter, recently met with Dr. Rys on behalf of the Stylus Studio® developer community. The two chatted about what's the scoop on Microsoft and XQuery technologies!

---

Ivan Pedruzzi: Hi Michael, and welcome to the Scoop. Nearly two-thirds of the Stylus Studio® XML developer community develops on the Microsoft platform, uses SQL Server, or uses Microsoft XML processing components. And as you know, we're nuts about XQuery at Stylus Studio®. So it won't come as much of a surprise when I say that we're especially excited to chat with you today.

Michael Rys: Well, we're excited about XML too. And I work for Microsoft. So it sounds like I'm in good company. [Laughs]

IP: Obviously XML is nothing new for Microsoft, in fact you've been something of a pioneer in this space. Could you take us back and explain how we got to where we are now, in terms of the planned XML support in the upcoming SQL Server 2005?

MR: It started with Microsoft SQL Server 2000, whose mission, at least in terms of XML support, was to provide the necessary facilities to work with XML representing relational data. To this end, we rolled out several technologies, notably Microsoft SQLXML server-side and client-side components. The client-side component has been updated over so called web-releases; we're currently shipping Version 3.0, and we'll be shipping Version 4.0 with SQL Server 2005. SQL Server 2005 provides all sorts of XML components, including utilities and APIs for simplifying working with relational and XML data such as XML Schema annotations for bi-directional mapping between relational databases and XML.

And just so readers aren't confused (and make sure your proofreader get this right!): 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.

IP: Thanks for that clarification… but could you have picked a more confusing naming scheme?

MR: Well, I'm just the XML standards guy here, not the marketing genius [laughs]. Besides, we were there first [evil laugh — just kidding — Ed.].

IP: Okay. So, what are Microsoft's primary goals in terms of XML support in the upcoming SQL Server 2005?

MR: What we're seeing today is that more and more people want to work with XML data natively, and we're moving to support them. For various reasons, developers want to be able to query an XML document, retrieve some information, reshape it, and propagate it to another context -- often relational, but also flat files, EDI, Web services, etc. In response, we made several big decisions — for starters, we're adding native XML storage capabilities to SQL Server 2005 to make SQL Server a natural choice for storing XML documents with all the benefits of a mature database management system. Also, we recognize that our customers need an efficient, declarative way to unlock the information stored in the XML, that is, to query and transform the native XML data in the database. We think — big surprise — that that way is XQuery, so we're integrating an XQuery processing facility into the SQL Server 2005 database to query the underlying native XML storage.

IP: Well, we've been keen on XQuery for quite some time. It's only a matter of time before it takes off, and facilities like the ones you're planning for SQL Server 2005 will only accelerate its adoption. Speaking of SQL Server 2005, what's its status? When are you shipping, and what kind of XQuery support will make it into that release?

MR: We're still targeting Q1 for SQL Server 2005 Beta 3, but its delivery will depend on the feedback we get from customers and partners. As far as planned support for XQuery, we're working off the W3C XQuery Working Draft of July 2004 and will provide support for a subset of the language. There are two reasons for this approach: Initially we've been heads-down focused on building the necessary architecture to handle complex XQuery processing, and some of the more complex features of XQuery will not be included as the standards committee has yet to provide a final recommendation.

IP: I think we're all eager for the recommendation!

MR: Indeed! [laughs] 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.

IP: And the SQL Server 2005 GA?

MR: Currently, the plan is to ship Microsoft SQL Server 2005 sometime this summer though the exact date has not been publicly announced. I don't myself have much impact on that ship date, but our primary focus is getting feedback from customers and partners. The goal is to ship a quality release and our customers and partners are the only ones that can tell us when the product is ready.

IP: Switching gears a bit from the server side to the client side — a lot of our user community comes from an XSLT development background [Stylus Studio® started out as an XSLT stylesheet development tool, hence the 'Stylus' in Stylus Studio® — Ed.] A lot of us use Microsoft components like MSXML and System.XML to build XML applications, and we've made a business out of providing editing and debugging support for those components. Do you have any plans to release some kind of XQuery processor component like you did for XSLT?

MR: The answer is a bit complicated.

IP: I have time.

MR: [laughs] 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.

We do want to add more XML features to the .NET framework (System.XML), although for various reasons, we recently pulled XQuery support from the upcoming version 2.0 of the .NET Framework after consulting key customers and partners and looking at the ship dates for the .NET Framework and the XQuery specification. You can read more about that decision at the MSDN website. We're not ruling out an XQuery implementation in the middle tier, but that's a decision that we'll base on customer demand going forward.

IP: No stand-alone XQuery processor component? What about the SQL Server XQuery processor — can't that technology be released as some kind of stand-alone component?

MR: Unfortunately, no. 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.] It's just another reason why we think that XQuery is perfect for the server-side, and why we're confident that we'll be able to roll out XQuery functionality over time in such a way to ensure the same quality of service that our users have come to depend on in the relational context. What's likely to happen going forward is that users will mix and match XML and relational data — our aim is to deliver this functionality without any performance penalty.

IP: That sounds promising, and I don't mean to hector, but our readers will want to know why you don't see a client-side XQuery processor as a part of your XQuery strategy. What about some kind of ADO or ODBC-like API for XQuery, for programmatically invoking XQuery expressions against SQL Server from client code, then iterating through the results?

MR: I don't mind — it's a legitimate question. And the answer is that there are a lot of technologists at Microsoft currently looking into the best way of providing that kind of functionality. 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.

IP: I think I'm going to have to start a petition...

MR: Well the thing about Microsoft is that we're very customer focused — always listening to what our customers have to say, and if enough customers ask us for something, we deliver. Developers working with these new technologies — XQuery, XSLT, XML transformation — should understand that if they feel that existing solutions don't provide the functionality that they need, they need to tell people like you or me. I think you have SSDN for this purpose, and I have a blog.

IP: Who doesn't? [laughs]

MR: Blogs, email... —

IP: Petitions!

MR: Petitions, if you'd like — the bottom line is that we can't provide useful solutions from an ivory tower or within a vacuum. Users need to inform vendors and the standardization bodies alike. Such communication is crucial to how XQuery — and other emerging XML technologies — will evolve over time.

One of the interesting 'side-effects' of XQuery as a language is that its very existence has already had a big impact on a lot of the internal Microsoft languages folks. We're seeing that that a lot of developers don't want to use DOM. XQuery is just having a huge impact on existing programming languages. Take C-omega. It's an ongoing project at Microsoft Research, combining, among other things, the notion of set-based programming into C# - it's some very powerful stuff.

IP: Power to the people, indeed! I should quickly point out to our Java developer audience here that you can access SQL Server today using an XQuery/XQJ implementation like DataDirect XQuery, and that they're signing up beta testers. But you're right — SSDN is a vibrant community of users who bring a lot of experience to the table, and dialog with them is vital. We understand that we're not the only smart people in this space.

MR: Ha. (Laughs)

IP: What about Microsoft's planned tools support for XQuery?

MR: SQL Server 2005 does not include any new XQuery tools at the moment; however I do think that XQuery, being a new technology, could really benefit from tools support. From what I've seen of Stylus Studio® at the XML 2004 Conference and Exposition, your support for XQuery extensions, XQuery mapping and debugging — that's interesting stuff! Definitely a good thing for software developers, and a win-win for SQL Server and Stylus Studio® users alike.

IP: Dr. Rys — your bottom line on XQuery?

MR: In summary, I'm very bullish. For three reasons —

• 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. I'm am also very interested in several related features including XQuery full text search and XQuery update, both of which are important use cases that will be tackled shortly thereafter. The XQuery stack is quickly evolving into a very compelling technology for declarative XML data processing.
• The SQL Standardization Committee — We're looking into mechanisms to leverage the work of the XQuery working group into existing SQL standard technologies, including mechanisms to query into SQL data types using XQuery, a subject I discussed at a recent talk at XML 2004.
• Vendor and Developer Adoption — Huge vendor and developer support — Stylus Studio® is a prime example — and encouraging side-effects on computer programming language development in general. Ultimately it is the customer who decides how useful a technology is, and I encourage your readers to learn more about and clearly understand where they can leverage XML and XQuery.

IP: Okay, one last question: is Rys pronounced "rice"? "ris"? "reese"?

MR: [laughs] I'm so glad you asked. I'll tell you, but only if you tell me whether it's "Eevan" or "Eyevan".

IP: And then maybe we can tackle es-cue-el versus sequel!

MR: That's currently in committee [Ed: In truth, the committee has decided, it's es-cue-el :) ].

IP: Michael, thanks very much for your time. It was an honor.

MR: You're quite welcome.

Editor's Note: If you liked this interview, consider subscribing to The Stylus Scoop, our bi-monthly XML developer newsletter, or emailing this article to a friend!

Prev: "Dr. Michael Kay on XML Technologies" Next: "Mike Olson on XQuery & Database Tech"