XPath vs. XQuery

XPath and XQuery are similar in some ways. XPath is also an integral part of the XQuery complete. Both languages can select data from either an XML document or an XML document repository. This article provides an overview of XPath and XQuery, and how to use XQuery extensions to XPath.

Although both XPath and XQuery can achieve some of the same functionality, XPath is concise and XQuery is more powerful and flexible. XPath is a good fit for many queries. For example, creating an unordered list of phone numbers from some records in an XML document is easiest with XPath implementations. However, if you need to express more complex expressions that record selection criteria, transform result sets, or make recursive queries, you need to use XQuery.

Xpath

XPath is a domain-specific language (domain-specific Language, DSL) and quickly becomes an important part of other, more generic languages. Programming languages combine XPath with modules and classes, sometimes even directly into the language's syntax. This is similar to the case of a previous regular expression.

XPath is popular because XPath can save a lot of time and effort for developers when extracting specific data from an XML document. Even people who have never been in touch with XPath can quickly take advantage of their powerful features. For example, the XML fragment in Listing 1.

Listing 1. XML Document

   <users>    <user>      <name>        <first>Lola</first>        <last>solis</ last>      </name>      <age>2</age>    </user>    <user>      <name>        <first>Nina</first>        <last>Serafina</last>      </name>      <age >4</age>      <visits>        <first>2008-01-15</first>        <last>2008-02-15 </last>      </visits>    </user>    <user>      <name>        <first> tracy</first>        <last>Keller</last>      </name>      <age>35</age>    </user>  </users>

If you need to get a list of the names of teenagers in your document, you can use the following XPath expression.

Listing 2. Select the last name of a user under 18 years of age

  /user[age Lt 18]/name/last/text () (: Result      Solis      Serafina:)

Imagine how much code you would have to write if you didn't use XPath to extract the same data. Even with the help of regular expressions, it takes a bit of brains to get rid of the values in the last tag of the node you are accessing.

The above XPath expression is not only accurate but also very clear and understandable. Even for those who do not understand XPath, a quick glance can understand the effect of this expression. XPath works because it is very powerful and has a long history of development. No matter how complex the structure, this language can understand the nodes in the XML document, and more importantly, understand the relationships between these nodes. Therefore, you can write an exact expression to represent elements and element values, as well as attributes, processing instructions, and so on.

Many XML queries are difficult to express in a clearer, more accurate way than XPath. But the inherent DSL features of XPath and its design goals have brought great limitations to programmers. The following section provides a brief overview of the XQuery language and presents an issue that XPath cannot solve separately. These issues require programmers to bypass XPath and turn to tools such as XQuery.

Xquery

Since XQuery natively supports XPath as part of the XQuery syntax, it is clear that XQuery can accomplish any task that XPath can accomplish. But XQuery is Turing-complete (turing-complete), which can be seen as a universal language, so it is easy to overcome many of the limitations of XPath, but at the cost of a slight increase in complexity.

Overview

XQuery employs a simple syntax that mixes XML, XPath, annotations, functions, and the specialized expression syntax that binds them together. The XQuery code consists entirely of expressions, without statements. All values are sequences, and simplicity is the most important for this language. So the expression Hi and 2 * 2 both are legal XQuery code that can be executed without any preparation or modification. XQuery is a high-end, strongly typed functional language (with no side effects) and is ideal for expressing queries that fetch data from an XML document or a large XML repository (repository). Finally, it is very similar to SQL. However, XQuery also provides additional functionality to express arbitrary transformations of the result set. Just as retrieving data from an XML document should use an XPath, you should use XQuery when retrieving and transforming data from a large XML repository.

Converting result Sets

The most prominent limitation of XPath is that there is no way to convert a result set. It is assumed that the results returned by the previous XPath query (listing 2) should be sorted alphabetically, as shown in Listing 3.

Listing 3. Alphabetically ordered results

Serafinasolis

cannot be done using XPath. You must write code in a different language (such as XQuery) or use a specialized private XPath extension to sort the results.

XQuery, on the other hand, allows you to sort the results or convert them into HTML, CSV, SQL, and any other text-based format. The most common type of conversion for XQuery is XML-to-XML conversion. Typically, large XML databases contain a large number of complex, entangled XML documents that are not needed by client applications. XQuery allows clients to precisely describe the type of XML document that they want the server to return. By providing an XQuery interface, the server can avoid saving data in multiple modes. In addition, using XQuery to transform client data is often much simpler and faster than using Perl, Java, or other commonly used computer languages. Of course, using XQuery to transform data while retrieving data in the current implementation is much faster than converting it later with XSLT.

In order to enter both record selection criteria and result conversion directives, XQuery provides an attribute called FLWOR (read as "flower") expression. The letters in this abbreviation represent,, for let where ,, order by and respectively return . This is the element that makes up the FLWOR expression. FLOWR expressions contain at least some of these elements, in general in the order in which abbreviations are foreshadowed. All FLOWR expressions begin with a for or let expression, ending with a return expression. If you are familiar with SQL, you may already understand what I said earlier. Here is a simple flowr expression borrowed from Edwin Markham's poem "Outwitted" (shown in Listing 4).

Listing 4. Simple FLWOR expression

Let $xml: =   <a>    <one>she drew a circle that shut me out</one>    <two>heretic Rebel, a th ing to flout</two>  </a>return $xml//one/text () (: Result    "She drew a circle that shut me out":)

Listing 5 shows how to apply a simple FLOWR expression to the XML in Listing 1 (for the sake of simplicity, the manifest _XML from Listing 1_ replaces the real XML).

Listing 5. Simple FLWOR expression

Let $xml: = _xml to Listing 1_for $user in $xml//user[age lt 18]order by $user/name/lastreturn $user/name/last/text () (: R Esult     Serafina     Solis:)

If you want the query to return an HTML fragment and represent the result as an ordered list, use the XQuery shown in Listing 6.

Listing 6. FLWOR expression that outputs an HTML sequence table

Let $xml: = _xml to Listing 1_return <ol>{for $user in $xml//user[age lt) Order by $user/name/last return <l i>{$user/name/last/text ()}</li>}</ol> (: Result <ol><li>Serafina</li><li> Solis</li></ol>:)

Notice how the XML and XQuery in Listing 6 are visually and effectively combined.

Back to top of page

Represents more complex record selection criteria

In addition to converting the retrieved data, using XQuery to find data is much better than XPath. XQuery and XPath overlap frequently, helping programmers to better express queries. For example, listing 7 places the XPath expression fragment age lt 18 in the clause of the FLWOR where expression.

Listing 7. Using XPath constraints in XQuery

Let $xml: = _xml to Listing 1_return  <ol>{for    $user in $xml//user    where $user/age lt-    order by $ User/name/last    return <li>{$user/name/last/text ()}</li>  }</ol>

The result of the expression in Listing 7 is exactly the same as the result of the expression in Listing 6. But XQuery where clauses are much more flexible than XPath's syntax for constraining. wherean XQuery clause can contain arbitrarily complex nested expressions and can even contain function calls. XQuery has no restrictions on record selection expressions.

Back to top of page

Using Functions and recursion

XPath does not support functions, but XQuery provides a number of important built-in functions and operators, and it also allows users to define their own functions. XQuery functions are strongly typed, support recursion, and can be declared as intrinsic or external functions. An intrinsic function is a standard function that follows the function declaration immediately after the function body. An external function is an open implementation of a function declaration type that allows a user to define a function body in a different programming language.

Although recursion is not necessarily the best way for developers to perform daily tasks, it is convenient for XML that contains multiple layers of nested nodes. For example, the functions defined in Listing 8 transform-names .

Listing 8. function to modify the name of a node in an XML document

(: Part 1:) define function transform-names ($node as Node ()) as node () {Element{replace (name ($node), "_", "-")} {$no De/text (), for $subnode in $node/* return Transform-names ($subnode)}} (: Part 2:) let $xml:=<item> &LT;ITEM_TYPE&G t;book</item_type> <contributors> <author> <first_name>Charles</first_name> &L T;last_name>edward</last_name> 
transform-namesThe function is the first piece of code in Listing 8 and can accept any complex XML document or node. For each XML tag name, the function will have an underscore (_) in it, which is a hyphen (-).
Performing recursion in this case makes it very easy to traverse the document structure. Moreover, the function is refined (only 3 lines of code!) ), easy to maintain, can be used for any XML document or node that does not contain attributes. Although it's a bit difficult to fully understand the function at first--especially for programmers who seldom use recursion--it's easy to guess how to modify a function if you delete an underscore instead of replacing it with a hyphen.
Back to top of page
Express Connection (join)
XPath does not provide a way to connect an XML node in a query. However, as with SQL, which provides the natural syntax for representing table joins in queries, XQuery also provides a way to connect an XML node set intuitively (at least for SQL users). Listing 9 shows how to use the connection in XQuery.
Listing 9. XQuery Connection Expressions
(: Part 1:) let $authors: = <authors> <author> <name>harold abelson</name> <books > <isbn>978-0-07-000422-1</isbn> <isbn>978-0-262-01063-4</isbn> &LT;/BOOKS&G    T </author> <author> <name>paul graham</name> <books> <isbn>978-0-13       -370875-2</isbn> <isbn>978-0-13-030552-7</isbn> <isbn>978-0-596-00662-4</isbn> </books> </author> <author> <name>apostolos-paul refenes</name> <bo oks> <isbn>978-0-471-94364-8</isbn> <isbn>978-981-02-2819-4</isbn> </book S> </author> </authors> (: Part 2:) let $books: = <books> <book> <title>struc Ture and interpretation of computer programs</title> <isbn>978-0-07-000422-1</isbn> </book&gt    ; <book>     <title>turtle geometry</title> <isbn>978-0-262-01063-4</isbn> </book> <bo    ok> <title>ansi Common lisp</title> <isbn>978-0-13-370875-2</isbn> </book>    <book> <title>on lisp</title> <isbn>978-0-13-030552-7</isbn> </book> <book> <title>hackers and painters</title> <isbn>978-0-596-00662-4</isbn> < /book> <book> <title>neural Networks in the capital markets</title> <isbn>978-0-47 1-94364-8</isbn> </book> <book> <title>neural Networks in financial engineering</tit le> <isbn>978-981-02-2819-4</isbn> </book> <book> <title>handbook of Arti Ficial intelligence</title> <isbn>978-0-201-16889-1</isbn> </book> <book> &L T;title>artificial inTelligence programming</title> <isbn>978-0-89859-609-0</isbn> </book> <book> <title>a New Guide to Artificial intelligence</title> <isbn>978-0-89391-607-7</isbn> < /book> <book> <title>artificial intelligence</title> <isbn>978-0-08-034112-5</i sbn> </book> <book> <title>artificial intelligence</title> <isbn>978-0-63 1-18385-3</isbn> </book> </books> (: Part 3:) return <books-complete-info>{for $book in $b ooks/* for $author in $authors/* where $book/ISBN = $author//isbn and (contains ($book/tit Le, "LISP") or contains ($book/title, "neural")) Order by $book/title return <book>{$book/*, $ Author/name}</book>}</books-complete-info>
The 1th and 2nd parts of listing 9 assign XML documents to variables authors and books. Some nodes in books are related to nodes in authors, and the book node's ISBN appears in the list of author nodes.
The XQuery join expression in part 3rd of the list consists of a new XML document, Books-complete-info (see Listing 10), where the book node contains the author's name.
The 3rd part of the code in Listing 9 has several points to note. The two expressions in the beginning section for indicate to XQuery that this is a join expression. The WHERE clause is conceptually similar to the SQL connection statement. Note, however, that the author node may have multiple ISBN, which requires that the where clause must state: "The book's ISBN is in the author's ISBN". More like a sub-selection in a SQL where clause, but XQuery syntax looks more intuitive and natural. Of course, XQuery expressions are also more precise.
Listing 10. Results of an XQuery join expression
<books-complete-info>  <book>    <title>ansi Common lisp</title>    <isbn> 978-0-13-370875-2</isbn>    <name>paul graham</name>  </book>  <book>    <title>on lisp</title>    <isbn>978-0-13-030552-7</isbn>    <name>paul Graham </name>  </book>  <book>    <title>neural Networks in the capital markets</ title>    <isbn>978-0-471-94364-8</isbn>    <name>apostolos-paul refenes</name>  </book>  <book>    <title>neural Networks in financial engineering</title>    <isbn>978-981-02-2819-4</isbn>    <name>apostolos-paul refenes</name>  < /book></books-complete-info>
Back to top of page
Conclusion
As a mature DSL, XPath should be your first choice when extracting data deep in an XML document, or in a repository. However, XPath is not designed to handle various types of problems. As you can see in this article, XQuery extends the XPath to a large extent, if the data filtering criteria are complex, or if you need to return a sorted result set (special formatting) and other transformations, you can choose XQuery.
XPath vs. XQuery