XQuery 1.0 is a concise but flexible query language for XML. XQuery is the product of many years of work by individuals and companies from around the world. Actively developed by the World Wide Web Consortium (W3C) XML Query and XSL Working Groups from the first W3C workshop on Query Languages in 1998 through today, XQuery contains ideas that are both decades old and brand-new.

XQuery is mainly intended for use with XML data, but is also finding uses as a language for data integration, even with data sources that may not be XML but can be viewed through an XML lens. Time will tell how successful XQuery will become, but the stage is set for it to become for XML what Structured Query Language (SQL) has become for relational data.

At the time of this writing, XQuery 1.0 is still in the draft stage, at Last Call. Consequently, some aspects of the language will change between now and the final Recommendation (when it becomes a standard). As much as possible, anticipated changes are noted throughout this book, and also at the book's Web site at http://www.qbrundage.com/xquery.

Also, as can be expected with a new language still under development, some parts of XQuery will strike you as a little rough or overly complex. In such cases (such as the data model and type system described in the next chapter), the design rationale is explained and numerous examples are provided to ease the learning process.

The many examples in this book are based on the current draft specifications. To run these examples, you need an XQuery implementation; several are listed on this book's Web site.

The XQuery standard gives implementations discretion in how they implement many of its features. Consequently, no two XQuery implementations are exactly the same. As much as possible, I have noted these potential differences throughout the book. However, I do not explain how to use any particular XQuery implementation in this book—please consult the implementation's documentation for instructions and differences between it and the official standard.

A few words about the notation used in this book: Important words and phrases are italicized when first introduced. Examples are always set off from the main text using a fixed width font, and sometimes appear on separate lines like Listing 1.1.

this is the example

In some cases, it helps to see not only the example but also what the expected result of executing it should be. A => symbol, as shown in Listing 1.2, separates examples from their results.

example expression
=>
its result.

another example => another result

XML and XQuery are intricately tied to the Unicode character set (described in Chapter 8). To avoid confusion when describing some Unicode characters, I use the notation U+NNNN where NNNN is the corresponding hexadecimal number for that character (usually NNNN is a four-digit number). For example, U+003F is the question mark (?).

At some point, you should stop to wonder: Why use XQuery? Why not use some other XML query language, like XPath or XSLT? For that matter, why use a query language at all? Why not work with the XML data structures directly using an existing programming language and some XML API? These are important questions, so let's address them before diving into the technical features of the XQuery language.

You may also question whether XQuery is right for your application. Whether you're working with documents or databases, you may wonder whether XQuery is designed primarily for the other.

Some years ago, there were documents, databases, and programs. Documents were units of semi-structured data (mostly unstructured text with some structural “markup” signifying logical parts of the document) usually stored as standalone files. Databases were self-contained storage systems with highly structured data organized into rigid tables with typed columns. Programs were source code stored in flat text files and parsed on demand to extract structure and meaning.

Each of these had its own community happily evolving independently of the others, with different tools and terminologies. The document community had word processors, document storage systems, scripting languages, and search engines; the database community had query builders, B-trees, indices, query languages, and query processors; the programming community had editors, source control systems, programming languages, and compilers.

And then XML happened.

In many ways, XML has brought these communities together. The increased contact has led many to realize that the challenges in their field are identical in essence to challenges in the other fields. However, each community has independently discovered very different ways of solving the same problem. For example, few database systems use just-in-time compilation and code generation techniques that are today common in compiler implementations; conversely, few programming languages use indices and cost-based optimizers that are common in databases.

Perhaps the most electrifying effects of XML have occurred between the database and document communities. The difficulties involved with storing and querying semi-structured documents have gained new prominence among database vendors; at the same time, the document community increasingly treats documents as “views” over structured data that can be queried and transformed into other representations.

XQuery was designed by people from all three communities to solve common document, database, and programming tasks. In places, XQuery has made compromises to one community or the other; for example, XQuery uses ordered sequences, regular expressions, recursion, and untyped data (document-centric features that are difficult for databases), but also supports joins and transformations, strongly-typed data, and allows expression evaluations to be reordered or skipped entirely through optimization (database-centric features that are difficult for document processors).

XQuery is a query language for both XML documents and databases. It makes no distinction between the two; to XQuery, it's all XML.

XQuery can handle both ordinary XML and XML associated with an XML schema. These are colloquially known as untyped XML and typed XML, respectively.

If all your XML data is untyped, you may think that you don't need to understand XML Schema, and you're partially correct. However, you do need to understand the XQuery type system, which plays a major role.

XQuery uses XML Schema 1.0 as the basis for its type system. Consequently, these two standards share some terminology and definitions. XQuery also provides some operators such as import schema and validate to support working with XML schemas.

The Types You Need

Every XQuery expression has a static type (compile-time) and a dynamic type (run-time). The dynamic type applies to the actual value that results when the expression is evaluated; the value is an instance of that dynamic type. The static type applies to the expression itself, and can be used to perform type checking during compilation. All XQuery implementations perform dynamic type checking, but only some perform static type checking.

Figure 1.1 depicts the XQuery types you need to know. Arrows show inheritance, and dotted lines indicate that some types in between have been omitted.

Figure 1.1. Part of the XQuery type system

Every XQuery value is a sequence containing zero or more items. Each individual item in a sequence is a singleton, and is the same as a sequence of length one containing just that item. Consequently, sequences are never nested.

Every singleton item in XQuery has a type derived from item(). The item() type is similar to the object type in Java and C#, except that it is abstract: you can't create an instance of item(). (It's written with parentheses in part to avoid confusion with user-defined types with the same name and in part to be consistent with the XPath node tests.)

As shown in Figure 1.1, items are classified into two kinds: XML nodes and atomic values. Nodes derive from the type node(), and atomic values derive from xdt:anyAtomicType. Like item(), the node() and xdt:anyAtomicType types are abstract.

You are probably already familiar with the seven XML node kinds depicted in Figure 1.1. XQuery provides several ways to create instances of XML nodes, which we'll explore later in this chapter and in Chapter 7.

Finally, there are 50 kinds of atomic types. Of these, you really only need to know fourteen—ten from XML Schema and four new ones (including the xdt:anyAtomicType) added by XQuery. The types you need to know are depicted in Figure 1.1. We explain them all in Chapter 2; some of their meanings are clear already from their names. Many examples of these types occur throughout the rest of the book.

All of the atomic type names are in one of two namespaces: The XML Schema type names are in the XML Schema namespace http://www.w3.org/2001/XMLSchema, which is bound to the prefix xs. The XQuery type names are in the XQuery type namespace http://www.w3.org/2003/11/xpath-datatypes, which is bound to the prefix xdt. These prefixes are built in to XQuery, and we'll use them throughout the book. (The namespaces are versioned to the current draft. The values given here correspond to the Last Call drafts available at the time of publication.)

Finally, it's worth mentioning that every user-defined type derives from one of the XML Schema built-in atomic types. The four XQuery atomic types, the seven node kinds, item(), and node() do not allow user derivation. In particular, it isn't possible to create your own node kind, although it is possible to create structural (complex) types using XML Schema and the import schema operator (see Chapter 9). Not all implementations support user-defined types and schema import.

Figure 1.2 presents a prototypical XQuery for your reading pleasure. Each query consists of a prolog and/or a body. The prolog, if any, sets up the compile-time environment (schema and module imports, namespace declarations, user-defined functions, and so on). The body, if any, is evaluated to produce the value of the overall query.

Figure 1.2. Anatomy of an XQuery

The rest of this chapter highlights the various kinds of expressions that can occur in the prolog and body of an XQuery, and the remaining chapters drill into the details.

Every XQuery expression evaluates to a sequence (a single item is equivalent to a sequence of length one containing that item). Items in a sequence can be atomic values or nodes. Collectively, these make up the XQuery Data Model, described in Chapter 2.

XQuery is primarily designed as a strongly-typed language, meaning that every expression has a compile-time type, and must be combined with other expressions that have compatible types. When types are incompatible, the error can be detected and reported early (at compile-time). However, XQuery allows implementations to perform dynamic type checking instead, in which these errors are reported only during execution.

To understand the difference, consider the expression in Listing 1.3. If an implementation supports static typing, then this query will produce a compile-time error, because the if expression might evaluate to a string and strings cannot be added to integers. In implementations that use dynamic typing, the result depends on the value of the variable $foo. If it is true, then the query will succeed (because if evaluates to an integer); if it is false, then it will raise a dynamic type error.

13 + if ($foo) then 30 else "0"
=>
43 or a type error, depending on the implementation and $foo

This book mostly describes the type rules in general, without respect to when they are applied. Consult your XQuery implementation's documentation to determine what kind of type checking it performs.

Next, let's turn our attention to the various kinds of XQuery expressions.

In XQuery, the whitespace characters are space (U+0020), tab (U+0009), carriage return (U+000D), and new line (U+000A). XQuery allows descriptive comments to appear anywhere that whitespace characters are allowed and ignored—which is almost everywhere. Their only purpose is to make code easier for humans to read.

XQuery comments begin with the two characters (: and end with the two characters :), as shown in Listing 1.4. Note that in places where whitespace characters are not ignored (such as string constants or direct XML constructors), comments are not ignored either but instead are treated as ordinary text.

(: You are here. :)
let $i := 42 (: This is also a comment. :)
return <x>(: This is not a comment. :)</x>
=>
<x>(: This is not a comment. :)</x>

As mentioned earlier, every query begins with an optional section called the prolog. The prolog sets up the compile-time context for the rest of the query, including things like default namespaces, in-scope namespaces, user-defined functions, imported schema types, and even external variables and functions (if the implementation supports them). Chapter 5 explains all of these expressions. Each prolog statement must end with a semicolon (;).

For example, the query prolog in Listing 1.5 declares a namespace, and then the body of the query uses it.

declare namespace x = "http://www.awprofessional.com/";
<x:foo/>

The query prolog also can be used to define global variables and to create user-defined functions for use in the rest of the query. The sample query shown previously in Figure 1.2 defines a recursive function, my:fact(), that computes the factorial of an integer, and then defines a global variable, $my:ten, that uses it.

Each function definition starts with the keywords declare function, followed by the name of the function, the names of its parameters (if any) and optionally their types, optionally the return type of the function, and finally the body of the function (enclosed in curly braces). Figure 1.3 illustrates all of these parts, using the same example as in Figure 1.2 but with types added.

Figure 1.3. A prototypical user-defined function

Queries may be divided into separate modules. Each module is a self-contained unit, analogous to a file containing code. Modules are most commonly used to define function libraries, which can then be shared by many queries using the import module statement in the prolog. Modules and user-defined functions are fully explained in Chapter 4. Note that not every implementation supports modules.

The constant value you will encounter most frequently is the empty sequence, written as left and right parentheses: (). Naturally enough, it denotes a sequence of length zero. XML constants are also very common, but are described later in Section 1.12. This section discusses constant atomic values such as booleans, strings, and integers.

"< & > are special characters in XML"
=>
"< & > are special characters in XML"

Although XQuery can be used to compute simple atomic values, more often it is used to produce XML output. This section briefly touches on the various ways to construct XML in a query (see Chapter 7 for more information).

All seven XML node-kinds are supported in XQuery. XML syntax can be used verbatim as XQuery expressions, as shown in Listing 1.7. These expressions are called node constructors because they construct XML nodes.

As you'll see in a moment, it's also possible to load XML from outside the query, or to compute parts of an XML structure using embedded XQuery expressions.

<hello world="this is" xmlns="http://www.awprofessional.com/">
  XQuery!!
  <!-- the last language you'll ever need -->
  <?or maybe not?>
  <![CDATA[Even CDATA sections are allowed]]>
</hello>

By leveraging the XML syntax with which you are already familiar, XQuery makes it simple to create XML values. However, the greatest flexibility comes in creating dynamic XML values that combine constant parts with parts that are computed by XQuery expressions.

To allow XQuery expressions to compute part or all of a node's content, XQuery reserves the two curly-brace characters ({}) in element and attribute constructors. The curly braces enclose an XQuery expression to be evaluated; the results of the XQuery are inserted into the XML structure at that point. Listing 1.8 demonstrates XQuery expressions in both attribute and element content.

<x y="6*7 = {6*7}">
It is { true() or false() } that this is an example.
</x>
=>
<x y="6*7 = 42">It is true that this is an example.</x>

To use the curly braces as ordinary characters in an XML constant, they must be escaped by doubling them ({{ and }}) as shown in Listing 1.9 or by using character references. XQuery supports hexadecimal and decimal character references (such as  ), as well as the five built in named entity references (such as &) from XML.

<add>
  {{ 1 + 1  = { 1+1 }}}
</add>
=>
<add>{ 1 + 1 = 2 }</add>

Only some kinds of nodes can have computed content. XML comments and processing instructions are always constants in XQuery, and are written using the usual XML syntax <!-- comment --> and <?processing instruction?>, respectively. Curly braces in them are treated as ordinary characters instead of as expressions.

In addition to the usual XML syntax, XQuery provides an alternate keyword-style syntax for creating nodes. This alternate syntax allows not only the content but also the node name to be computed (for elements and attributes). Otherwise, computed constructors have the same effect as direct XML syntax; it's a matter of personal choice which you use.

Element nodes can be constructed using the usual XML syntax shown in Listing 1.7 or using an alternate syntax, shown in Listing 1.10, that allows their names and content to be computed by XQuery expressions.

element { "any-name" } { "any content" }
=>
<any-name>any content</any-name>

Document nodes can be constructed only using this alternate syntax. Attribute and text nodes can be constructed using the alternate syntax, or can be constructed inside of XML elements as usual. Finally, namespace nodes are constructed only in element constants. All of these are shown in Listing 1.11.

document {
   element foo {
      attribute bar { 1 + 1 }
      text { "baz" }
      <x xmlns='urn:x'>Ordinary XML can be
      intermixed with the alternate syntax</x>
   }
}
=>
<foo bar="2">baz<x xmlns='urn:x'>Ordinary XML can be
      intermixed with the alternate syntax</x></foo>

An XQuery expression in a node constructor can result in the empty sequence, in which case it contributes nothing to the content, or it can result in a sequence containing more than one item. The rules in this case are somewhat complicated, but in general the values are separated by spaces. These effects are demonstrated in Listing 1.12.

<x y="{ () }">{ (1, 2) }</x>
=>
<x y="">1 2</x>

Constructing XML turns out to be a very intricate process, in part because there are so many special cases in XML and XQuery, like how whitespace characters are handled and how XQuery values are represented as XML. For a complete explanation of all the rules, see Chapter 7.

Not counting the type constructors mentioned in Section 1.11.4, XQuery defines 110 built-in functions, counted by name. Both built-in and user-defined functions are invoked by writing the function name followed by zero or more argument values in parentheses, like function(param1, param2). Function invocations are matched to function definitions by the function name and the number of arguments, which together are called the function signature.

For example, the number of items in a sequence can be counted using the count() function. A subsequence of several items can be selected using the subsequence() function. Sequences use 1-based indexing, so the first item in the sequence occurs at position 1. See Listing 1.13 for examples.

count(("a", 2, "c"))              => 3
subsequence((-5,4,-3,2,-1), 3)    => (-3, 2, -1)
subsequence((-5,4,-3,2,-1), 2, 3) => (4, -3, 2)

All of the built-in functions (except type constructors) belong to the namespace http://www.w3.org/2003/11/xpath-functions, which is bound to the prefix fn. This is also the default namespace for functions, which means that unqualified function names are matched against the built-in functions. For example, true() is the same as fn:true(), provided that you haven't changed the default function namespace or the namespace binding for fn. I generally omit the built-in prefix in this book.

Appendix C lists all of the built-in functions, sorted alphabetically for convenient reference, and you will encounter many of them throughout the following chapters.

Sequences of values are written with commas separating items in the sequence, as shown in Listing 1.14.

1, "fish"

Because the comma operator has the lowest precedence of all XQuery operators, sequences usually need to be enclosed in parentheses. In fact, parentheses can be used to group all kinds of expressions together, as shown in Listing 1.15.

()           => ()
(1, 2)       => (1, 2)
1 + 2 * 3    => 7
(1 + 2)*3    => 9

XQuery defines a rich assortment of other operators and expressions. In this chapter we scratch the surface of a few of them; for complete details, see Chapter 5 and Appendix B.

Some operators are unary prefix (such as - and +) or unary postfix (such as []), meaning they take a single operand and appear before or after it, respectively. Others are binary infix operators (such as or and +), meaning they appear between their two operands. Some operators are written using punctuation symbols (like * and /), while others are written using names (like div and intersect).

XQuery does not reserve keywords; instead, context is used to determine their meaning. Like XML, XQuery is a case-sensitive language. All XQuery keywords are lowercase.

true() and false()  => false()
true() or false()   => true()
not(false())        => true()

if (true()) then "true" else "false"
=>
"true"

if (expr < 0)
then "negative"
else if (expr > 0)
then "positive"
else "zero"

1 + 2      => 3
3 – 4      => -1
1 * 2      => 2
1 div 2    => 5E-1
1 idiv 2   => 0
1 mod 2    => 1
+1.0       => 1.0
-1.0       => -1.0
2.0 * 3    => 6.0
2E1 div 4  => 5E0

min((2, 1, 3, -100))        => -100
round(9 div 2)              => 5
round-half-to-even(9 div 2) => 4

string-length("abcde")               => 5
substring("abcde", 3)                => "cde"
substring("abcde", 2, 3)             => "bcd"
concat("ab", "cd", "", "e")          => "abcde"
string-join(("ab","cd","","e"), "")  => "abcde"
string-join(("ab","cd","","e"), "x") => "abxcdxxe"
contains("abcde", "e")               => true
replace("abcde", "a.*d", "x")        => "xe"
replace("abcde", "([ab][cd])+", "x") => "axde"
normalize-space("  a  b cd  e  ")    => "a b cd e"

string-to-codepoints("Hello")          => (72,101,108,108,111)
codepoints-to-string((87,79,82,76,68)) => "WORLD"

1 eq 1 => true
1 eq 2 => false
1 ne 2 => true
1 gt 2 => false
1 lt 2 => true

(1, 2, 3) = 4     => false
(1, 2, 3) = 3     => true
(1, 2) = (3, 4)   => false
(1, 2) != (3, 4)  => true
(1, 2) = (2, 3)   => true
(1, 2) != (2, 3)  => true
(1, 2) != (1, 2)  => true

<a/> is <b/>                       => false
<a/> isnot <a/>                    => true
doc("test.xml") is doc("test.xml") => true
x/.. << x                          => true

You have seen how to construct XML and how to operate on sequences of nodes and values, but of course the most important topic is the application of XQuery to existing (external) XML sources. This section explores the use of existing XML data. In the examples given in this section and the remainder of this chapter suppose team.xml is the XML document shown in Listing 1.26.

XQuery provides several functions to access existing XML data, including the doc() function. This function is similar to the document() function in XPath and XSLT: It takes a single argument, which is a string URI pointing to the XML source to be loaded, and returns the resulting document. For example, doc("team.xml") accesses the data source team.xml.

Given an XML document, the next step is to select some of the nodes it contains. Just as XSLT 1.0 used XPath 1.0 to select nodes, XQuery uses the XPath 2.0 path syntax. By conscious design, these paths are somewhat similar to file system paths, because both navigate a hierarchy of information.

<?xml version='1.0'?>
<Team name="Project 42" xmlns:a="urn:annotations">
  <Employee id="E6" years="4.3">
    <Name>Chaz Hoover</Name>
    <Title>Architect</Title>
    <Expertise>Puzzles</Expertise>
    <Expertise>Games</Expertise>
    <Employee id="E2" years="6.1" a:assigned-to="Jade Studios">
      <Name>Carl Yates</Name>
      <Title>Dev Lead</Title>
      <Expertise>Video Games</Expertise>
      <Employee id="E4" years="1.2" a:assigned-to="PVR">
        <Name>Panda Serai</Name>
        <Title>Developer</Title>
        <Expertise>Hardware</Expertise>
        <Expertise>Entertainment</Expertise>
      </Employee>
      <Employee id="E5" years="0.6">
        <?Follow-up?>
        <Name>Jason Abedora</Name>
        <Title>Developer</Title>
        <Expertise>Puzzles</Expertise>
      </Employee>
    </Employee>
    <Employee id="E1" years="8.2">
      <!-- new hire 13 May -->
      <Name>Kandy Konrad</Name>
      <Title>QA Lead</Title>
      <Expertise>Movies</Expertise>
      <Expertise>Sports</Expertise>
      <Employee id="E0" years="8.5" a:status="on leave">
        <Name>Wanda Wilson</Name>
        <Title>QA Engineer</Title>
        <Expertise>Home Theater</Expertise>
        <Expertise>Board Games</Expertise>
        <Expertise>Puzzles</Expertise>
      </Employee>
    </Employee>
    <Employee id="E3" years="2.8">
      <Name>Jim Barry</Name>
      <Title>QA Engineer</Title>
      <Expertise>Video Games</Expertise>
    </Employee>
  </Employee>
</Team>

For example, suppose you want to select the Team element at the top of the document. This can be done using the XQuery doc("team.xml")/Team. The slash operator iterates through every node in the expression on the left (the context), and for each such node performs the selection on the right (the step). In this case, the context is the root node of the document team.xml, and the step selects its Team element children. Any number of steps may be combined together in a path.

To select attribute nodes instead of elements, you can use the @ symbol in front of the step name. For example, doc("team.xml")/Team/@name selects the attribute name="Project 42".

Paths are easily one of the most important types of expressions in XQuery. Paths provide many other navigation operators for moving around the hierarchy, selecting different kinds of nodes, and filtering the nodes selected. Chapter 3 covers paths and navigation more generally.

Variables in XQuery are written using a dollar sign symbol in front of a name, like so: $variable. The variable name may consist of only a local-name like this one, or it may be a qualified name consisting of a prefix and local-name, like $prefix:local. In this case, it behaves like any other XML qualified name. (The prefix must be bound to a namespace in scope, and it is the namespace value that matters, not the prefix.)

Several different expressions in XQuery can introduce new variables into scope. These are described in later in the book: function definitions (Chapter 4), global variable declarations (Chapter 5), FLWOR and quantification (Chapter 6), and typeswitch (Chapter 9). If there is already a variable in scope with that name, then the new definition temporarily overrides the old one.

It's worth observing that XQuery variables, despite being called “variable,” are actually immutable. In fact, everything in XQuery is read-only; in XQuery 1.0, no expressions can change the values of variables or XML data. There are proposed extensions to XQuery (see Chapter 14) that would allow some values to be modified and may appear in future versions of the standard (and possibly the implementation you use today).

The central expression in XQuery is the so-called “flower expression,” named after the first letters of its clauses—for, let, where, order by, return—FLWOR. FLWOR is an expression with many features, which are covered completely in Chapter 6.

The FLWOR expression is used for many different purposes in XQuery: to introduce variables, to iterate over sequences, to filter results, to sort sequences, and to join different data sources. The FLWOR expression in Listing 1.27 uses all five clauses to iterate over an existing document and return a result.

for $i in doc("orders.xml")//Customer
let $name := concat($i/@FirstName, $i/@LastName)
where $i/@ZipCode = 91126
order by $i/@LastName
return
  <Customer Name="{$name}">
    { $i//Order }
  </Customer>

The for and let clauses may appear in any order relative to one another, and there may be any number of each, provided there is at least one for or let clause. Each for clause iterates through a sequence, binding a variable to each member of the sequence in turn. Each let clause assigns a variable to the value of an expression. Every variable introduced this way is in scope for the remainder of the FLWOR expression, including any for/let clauses that follow.

The optional where clause filters the possibilities, and the optional order by clause sorts the result into a particular order. Finally, the return clause constructs the result, which can be any expression at all.

A very simple FLWOR is shown in Listing 1.28. This example declares a variable ($variable) using a let clause, and then returns some expression (which might use that variable).

let $variable := "any expression here"
return concat("xx", $variable, "xx")
=>
"xxany expression herexx"

A more complex example is shown in Listing 1.29. This FLWOR iterates through a sequence, and returns only those members that are greater than 3.

for $i in (1, 2, 3, 4, 5)
where $i > 3
return $i
=>
(4, 5)

Often, simple FLWOR expressions can be expressed using paths instead. For example, Listing 1.29 could also be expressed as the path (1,2,3,4,5)[. > 3]. Path expressions are very concise, but can be difficult to comprehend.

FLWOR is especially useful when used together with paths. For example, consider the team.xml example in Listing 1.26. Suppose you want to list all employees alphabetically by last name. You can use a path to select the employee names, the tokenize() function to split the name into first and last parts, and then an order by clause to sort by the last name, as shown in Listing 1.30.

for $e in doc("team.xml")//Employee
let $name := $e/Name
order by tokenize($name)[2] (: Extract the last name :)
return $name

FLWOR is also commonly used to join a data source with itself or other data sources, as shown in Listing 1.31. For more examples, see Chapter 6.

for $i in doc("one.xml")//fish,
    $j in doc("two.xml")//fish
where $i/red = $j/blue
return <fishes> { $i, $j } </fishes>

XQuery distinguishes between static errors that may occur when compiling a query and dynamic errors that may occur when evaluating a query. Dynamic errors may be reported statically if they are detected during compilation (for example, xs:decimal("X") may result in either a dynamic or a static error, depending on the implementation).

Most XQuery expressions perform extensive type checking. For example, the addition $a + $b results in an error if either $a or $b is a sequence containing more than one item, or if the two values cannot be added together. For example, "1" + 2 is an error. This is very different from XPath and XSLT 1.0, in which "1" + 2 converted the string to a number, and then performed the addition without error.

XQuery also defines a built-in error() function that takes an optional argument (the error value) and raises a dynamic error. In addition, some implementations support the trace() function, which allows you to generate a message without terminating query execution. See Appendix C for examples.

Many other XQuery operations may cause dynamic errors, such as type conversion errors. As mentioned previously, often implementations are allowed to evaluate expressions in any order or to optimize out certain temporary expressions. Consequently, an implementation may optimize out some dynamic errors. For example, error() and false() might raise an error, or might return false. The only expressions that guarantee a particular order-of-evaluation are if/then/else and typeswitch.

Query languages are powerful tools for manipulating XML, and XQuery doesn't disappoint. With literally hundreds of operators and functions, it's a rich and feature-full language for constructing and navigating XML and typed values.

The core features of XQuery are its type system, XML constructors, navigation paths, and FLWOR (“flower”) expressions, all of which are explained in later chapters. XQuery also provides many useful operators (Chapter 5) and even allows users to define their own functions (Chapter 4).

For more information on the development of the XQuery standard, look no further than XQuery from the Experts: A Guide to the W3C XML Query Language by Howard Katz. Essays from many of the committee members themselves explain some of the design decisions made along the way.

Many great books on XML are available; two of the better ones are Essential XML: Beyond Markup by Don Box, Aaron Skonnard, and John Lam, and Learning XML by Erik Ray and Christopher Maden. If you believe that you've already mastered these basics of XML, then I highly recommend taking your skills to the next level with Effective XML: 50 Specific Ways to Improve Your XML by Elliote Rusty Harold.