XQuery Database Language for XML Achieves 1.0 Status

After its inception among members of the World-Wide Web Consortium as early as September 1999, their proposed crown jewel of the XML toolkit had been scheduled for formal adoption five years ago. Software vendors have already been selling Web services database development kits using primitive versions as a reference. Now, at long last, the W3C has formally adopted version 1.0 of XQuery, an XML-oriented query language that, a very long time ago now, seemed poised to change the history of Web applications.

The W3C catalogs some 48 commercial implementations of XQuery in commercial software. But years have passed, and many of the contributors to the XML Query Working Group - including IBM, Oracle, and Microsoft - have drifted apart in their concepts of online database architecture. Has time already run out for what had been one of the Web's most ambitious projects?

"Creating a new query language is a serious business," stated architect Don Chamerblin of IBM's Almaden Research Center, and his co-authors in the introduction to their 2003 book, XQuery from the Experts. "Many person-years have been spent in defining XQuery, and many more will be spent on its implementation. If the language is successful, developers of web-based applications will use it for many years to come."

XQuery adopts the premises of SQL, though applied to the realm of XML data. While data in relational databases tends to be flat, or tabular - or, to use the mathematician's term, in tuples - XML data is almost by definition irregular and nested. While conceivably any tabular data could be easily converted to XML using a simple parser, the converse is not necessarily true, as XML data tends to be subcategorized. As a result, one "record" from a SQL database perspective tends not to look like another "record."

So XQuery's mission is to enable a user, perhaps of a Web browser, to submit a complex query in a format that XML can parse. Imagine, for example, an online catalog application that had access to the inventories of multiple computer hardware vendors. A query could essentially ask for all the items available whose brand is "Soltek" and which has a "chipset" attribute set to "Via."

In other words, "Show me everything I can buy from Soltek that has a Via chipset." What am I talking about? This query is actually about motherboards, but notice I didn't have to say that up front. An XML database might contain all sorts of records for devices, some of which might be categorized using an attribute like "Display Type" for LCD monitors, or "Chipset" for motherboards.

Now, suppose all these vendors utilize XML databases. Conceivably the single query could be distributed to all those resources, with their multiple results being joined together. A separate language implementation called XSLT 2.0 (or XSL Transformations), also ratified today by W3C, has the job of transforming the results that meet the query criteria into a "stylesheet" of sorts, as though it were being reported back on screen (even if the screen is imaginary for the moment). This way, the results are reported back to XQuery with the proper types and restrictions applied.

"Since virtually any kind of information can be represented using XML, I expect XQuery to play a central role in unifying information from many different sources," Chamberlin said in a prepared statement this morning. "Companies across a wide range of industries can use XQuery to pull together structured and semi-structured information for processing in a unified way."

So you see what ramifications such a system could have. Today, consumers rely on services like PriceGrabber to maintain collective databases that go out and literally combine resources from participating vendors into a single source, where all the results are pre-arranged on tiers of Web pages. It's a colossal task, but PriceGrabber makes a living from it.

Imagine if Web services were constructed in such a way that you wouldn't need PriceGrabber. In such a world, you could pose the query yourself without anyone having to pre-compile the data. You could also tweak the results to suit your own tastes.

From a Web designer's standpoint, an XQuery environment would provide substantive differences as well. Today, simple blog providers and complex content management systems alike utilize MySQL as their underlying database, even when the task of regulating the underlying data in tabular format is time-consuming, and perhaps unproductive. As long as XML is being used more and more to encapsulate the underlying data of template-oriented pages anyway, an XQuery processor rather than a SQL-based one could be radically simpler, and perhaps much faster as well.

Had such a standard been widely adopted five years ago, the Web today might look very, very different.

"The design process used by the Query working group is probably not the fastest way to design a query language," the Chamberlin author team noted in 2003, "and languages designed by large committees are not often noted for elegance and simplicity. Nevertheless, the members of the working group hope that their diverse backgrounds and interests have contributed to making XQuery robust for a broad spectrum of usage environments. Time and experience will provide a measure of their success."

Such notices have been inscribed on the dedications of time capsules, the meaning of whose contents are often lost to history. Now it may become the task of enterprising new companies such as DataDirect, which has had an XQuery processor implementation based on reference designs for a few years, to promote the old new way to work over the more centralized approach to data management currently being exhibited by Microsoft, Oracle, and even Google. While almost everyone supports XQuery on paper, it's taken this long to actually get it done.

8 Responses to XQuery Database Language for XML Achieves 1.0 Status

© 1998-2024 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.