Despite a shortage of sophisticated XML query tools, Internet demands have forced companies to present their data in various formats. In one sense little has changed, as SQL queries have long been used to combine data for different purposes and audiences. Now however, the output is XML, and while the tools used to generate or consume XML may be different, the structure is similar to structures created by traditional report writers.

Relational databases have neither hierarchy nor sequence, but XML uses both to structure data. This is a good match for the way XML data is used. Most Web sites use data from relational databases, though it rarely looks relational on a Web page. Nobody wants to present users with a series of two-dimensional tables, telling them how to join the tables in their minds to see the relationships. Instead, relational data is used to build hierarchical representations of the data for users. Similarly, most Web messages have a strongly hierarchical organization that looks nothing like the relational tables. For both Web sites and Web messages, data is generally exchanged as XML. Web sites convert the XML to HTML using stylesheets, and Web messages exchange data directly as XML.

Companies basically have four choices when deciding how to use relational data in XML applications - custom coding, proprietary XML extensions from database vendors, SQL 2003's SQL/XML extensions, and XQuery.

Any of these approaches can be used, but they have very different ramifications for the architecture of software systems.

Custom programming is probably the most widespread approach to integrating XML and relational data. These programs use JDBC or ODBC to issue SQL queries to query the database, create XML structures using APIs like DOM or SAX, and use XSLT to transform structures or format XML for display as HTML.

This approach is standards-based and portable but requires much tedious coding, and the same information is often represented in several intermediate formats. This code is difficult to maintain when new formats are required or existing formats change. It is tricky to make these applications perform well, and not usually cost effective since new programming is needed for each desired format.

Relational vendors have long recognized the need for integration with XML, providing SQL extensions and other tools for their products. These tools vary widely in quality, performance, and usability and have been important for the evolution of our understanding of XML query languages. For companies that can afford to rely on only one database vendor, proprietary tools can be a good alternative to custom coding, though they are inherently nonportable.

Recognizing the need for a standard for adding XML support to relational databases, INCITS, ANSI, and ISO have added XML publishing functions to SQL 2003. These functions are easy to learn and allow any desired XML structure to be created. As part of the SQL language, the full power of SQL is available to structure data; for an experienced SQL programmer, this is the simplest tool that solves the problem well, and it fits well into existing relational infrastructure. Portable implementations of SQL/XML are commercially available, using the standard JDBC API to access query results.

The W3C has designed the XQuery language to query XML in the same way that SQL queries relational data. Input and output of an XQuery are XML, and XQuery works efficiently for XML views of data sources that are not represented as XML. Most relational vendors are implementing XQuery based on SQL/XML views of their relational tables, and some third-party tools can provide XML views of any relational database, allowing data to be combined with XML files or XML represented using SAX or DOM in a program. Likely to become a Recommendation soon, XQuery easily combines multiple data sources making it a clear winner for data integration.

Both XQuery and SQL/XML are extremely useful for businesses that need a portable way to query their data to produce XML. XQuery is more powerful for data integration, and fits better into many XML environments. SQL/XML fits well into existing relational infrastructure, and requires little new learning from programmers.