XML Query Language (XQuery), designed to do for Web services what SQL did for relational databases, achieved fully
approved standard status from the W3C on Tuesday.
Approved with its companion standard, XSL transformations (XSLT) 2.0, XQuery offers the potential to simplify data handling in Web services applications and speed development, according to members of the W3C who worked on it.
"I think it's going to have a huge impact because it's a standard language for dealing with XML content from all manner of sources," Liam Quin, XML Activity lead at W3C. "Anyone working in an enterprise environment is going to have multiple data sources, multiple data bases. Having a single language to address multiple data sources and do integration is significantly going to cut the cost of application development."
What SQL has been for the relational database world of the client-server era, XQuery can be for the world of Web services and service-oriented architecture, Quin said. He pointed out that XQuery is from the lineage of SQL. Don Chamberlin, IBM fellow at the IBM Almaden Research Center, was co-inventor of the original SQL and was also one of the co-editors of XQuery 1.0. Jim Melton of Oracle Corp, who served as the XML Query Working Group co-chair, is also the editor of the ISO SQL standard.
In Tuesday's W3C announcement, Chamberlin said, "XQuery will serve as a unifying interface for access to XML data, much as SQL has done for relational data." With XML's ability to represent any kind of data, he said XQuery makes it possible to bring together both structured and unstructured sources and process it in a unified way.
It is no coincidence that XQuery and XSLT were approved on the same day, Quin said. XQuery, which had its beginning eight years ago when W3C held a meeting to explore XML query languages, took advantage of what had been learned in creating XSLT 1.0.
"XSLT has been a hugely successful language," Quin said. "We've learned a lot from XSLT and we realized we wanted XSLT 2.0 and XQuery to share as much as possible, so developers could move between one and the other and implementers could share code. Both working groups worked together, met jointly to develop those languages. They developed a common function library, a common typing system and a common data model."
Quin also noted that XQuery was designed to be optimized, just as SQL can be optimized. The optimization capabilities are one of the primary features where XQuery can make life easier for Web services developers, said Jonathan Robie, XQuery technology lead at DataDirect Technologies Inc. and one of the editors who worked on the language. He said a system using XQuery will know how to optimize processes.
"I don't know of a system that goes through your DOM calls and says I know what that person is trying to do and does optimization on it," Robie explained. "Procedural code tends to stay procedural. You tell the system what steps are to be taken. An XQuery system is going to optimize that stuff. It's going to look at all of what you're doing and simplify things so that the code runs more efficiently."
Robie said developers are finding that XQuery offers efficiency that older languages cannot match. "We had guys who were working with Java APIs and SQL who did it that way because they wanted maximum efficiency. When they replaced it with XQuery they discovered the resulting system was running a lot faster."
Nancy Vodicka, a product marketing manager at DataDirect, said she has seen a developer replace 150 lines of SQL with one line of XQuery. "It greatly simplified his code," she said. "Got rid of 50 Java classes as well. So it was much easier to do the XQuery in the native XML rather than do all the conversions working with the SQL."
Robie said developers gain efficiency because of the declarative nature of XQuery and because it is all XML.
"If you're getting Web services requests, those requests typically have XML associated with them," he explained. "If you're doing Web services processing, you're calling other Web services as XML. You've got XML all over the place as native XML. The other thing is that you probably have a whole bunch of data sources that you need to access locally, things that nobody else has resource to except your Web services. You want to be able to create complex XML structures from that using the data from the incoming messages and the Web services calls that are going out. So you can write queries that will declaratively combine all this data to create any payload you need for a Web service.
"It makes data a lot easier for the developers by getting rid of the mismatch between the programming languages and XML," Robie explained. "It makes data easier for them by saying instead of having to learn a different API for every data source you can let your middleware figure out how to treat your data sources as XML. So you just have one query language and one data model. It works with all your different kinds of data to create the payloads that you need."
DataDirect is one of many vendors who have already implemented XQuery in their products. While not official and finally approved until this week, the standard has been in useable shape for several years. Quin explained that XQuery went to "final call" for suggestions and changes three years ago. But W3C received more than a thousand questions and suggestions from the developer community which had to be addressed before final approval. In the interim vendors including Microsoft, Oracle, IBM and BEA began implanting the standard anyway.
It will probably be several years before W3C considers developing XQuery 2.0, but Quin sees this as a plus because it assures developers, vendors and organizations using the standard that it will remain stable and unchanged for at least the rest of this decade.