XQuery is dependent on or related to a number of other technologies, particularly XPath, XSLT, SQL, and XML Schema. This section explains how XQuery fits in with these technologies.
XPath started out as a language for selecting elements and attributes from an XML document while traversing its hierarchy and filtering out unwanted content. XPath 1.0 is a fairly simple yet useful recommendation that specifies path expressions and a limited set of functions. XPath 2.0 has become much more than that, encompassing a wide variety of expressions and functions, not just path expressions.
XQuery 1.0 and XPath 2.0 overlap to a very large degree. They have the same data model and the same set of built-in functions and operators. XPath 2.0 is essentially a subset of XQuery 1.0. XQuery has a number of features that are not included in XPath, such as FLWORs and XML constructors. This is because these features are not relevant to selecting, but instead have to do with structuring or sorting query results.
The two languages are consistent in that any expression that is valid in both languages evaluates to the same value using both languages.
XPath 2.0 was built with the intention that it would be as backward-compatible with XPath 1.0 as possible. Almost all XPath 1.0 expressions are still valid in XPath 2.0, with a few slight differences in the way values are handled. These differences are identified in Chapter 25.
XSLT is a W3C language for transforming XML documents into other XML documents or, indeed, documents of any kind. There is a lot of overlap in the capabilities of XQuery and XSLT. In fact, the XSLT 2.0 standard is based upon XPath 2.0, so it has the same data model and supports all the same built-in functions and operators as XQuery, as well as many of the same expressions.
Some of the differences between XQuery and XSLT are:
XSLT implementations are generally optimized for transforming entire documents; they load the entire input document into memory. XQuery is optimized for selecting fragments of data, for example, from a database. It is designed to be scalable and to take advantage of database features such as indexes for optimization.
XQuery has a more compact non-XML syntax, which is sometimes easier to read and write (and embed in program code) than the XML syntax of XSLT.
XQuery is designed to select from a collection of documents as opposed to a single document. FLWORs make it easy to join information across (and within) documents. Also, XSLT 2.0 stylesheets can operate on multiple documents, but XSLT processors are not particularly optimized for this less common use case.
Generally, when transforming an entire XML document from one XML vocabulary to another, it makes more sense to use XSLT. When your main focus is selecting a subset of data from an XML document or database, you should use XQuery. The relationship between XQuery and XSLT is explored further in Chapter 25.
XQuery borrows ideas from SQL, and many of the designers of XQuery were also designers of SQL. The line between XQuery and SQL may seem clear; XQuery is for XML, and SQL is for relational data. However, increasingly this line is blurred, because relational database vendors are putting XML frontends on their products and allowing XML to be stored in traditionally relational databases.
XQuery is unlikely to replace SQL for the highly structured data that is traditionally stored in relational databases. Most likely, the two will coexist, with XQuery being used to query less-structured data, or data that is destined for an XML-based application, and SQL continuing to be used for highly structured relational data.
Chapter 24 compares XQuery and SQL, and describes how they can be used together.
XML Schema is a W3C standard for defining schemas, that can be used to validate XML documents and to assign types to XML elements and attributes. XQuery uses the type system of XML Schema, which includes built-in types that represent common datatypes such as decimal, date, and string. XML Schema also specifies a language for defining your own types based on the built-in types.
If an input document to a query has a schema, the types can be used when evaluating expressions on the input data. For example, if your item element has a quantity attribute, and you know from the schema that the type of the quantity attribute is xs:integer, you can perform sorts or other operations on that attribute's value without converting it to an integer in the query. This also has the advantages of allowing the processor to better optimize the query and to catch errors earlier.
XQuery users are not required to use schemas. It is entirely possible to write a complete query with no mention of schemas or any of the schema types. However, a rich set of functions and operators are provided that generally operate on typed data, so it is useful to understand the type system and use the built-in types, even if no schema is present. Chapter 13 covers schemas in more detail.