What Is XQuery and What Is It Used For?
Updated
XQuery is a query and transformation language for XML data. You use it to select, filter, reshape, and combine XML documents, and to build XML-backed applications when it runs inside an XML database such as eXist-db. It is the right tool when your data is XML (or XML-like, such as TEI, DocBook, or metadata records) and you need to search and restructure it rather than just store it. If your data lives in relational tables, SQL is the more direct fit.
What XQuery does
XQuery is standardized by the W3C and is deliberately expression-oriented: almost everything returns a value, and values are sequences of XML nodes or atomic items. That single idea covers the main jobs:
- Querying: find documents or fragments matching conditions, similar to how SQL filters rows.
- Transforming: convert one XML vocabulary into another (for example, TEI manuscripts into HTML pages).
- Constructing: build new XML directly in the query, which is how XQuery produces output for web pages and reports.
- Combining: join and merge data from multiple documents or collections in one expression.
A minimal example shows the shape of the language. Given a collection of <book> elements, this returns the titles of books published after 2000, wrapped in a new element:
<recent>
{
for $b in collection("/db/books")//book
where $b/year > 2000
order by $b/title
return <title>{ $b/title/text() }</title>
}
</recent>
The for/where/order by/return clause is the workhorse pattern. The curly braces switch from constructing XML into evaluating an expression, which is why XQuery can both query and generate markup in the same statement.
How XQuery differs from SQL and general-purpose languages
| Dimension | XQuery | SQL | General-purpose language (e.g., Python, Java) |
|---|---|---|---|
| Data model | Ordered sequences of XML nodes and atomic values | Tables of rows and columns | Arbitrary objects and structures |
| Typical strength | Nested, hierarchical, document-shaped data | Flat, relational data with joins | Application logic, I/O, everything else |
| Output | Often XML, HTML, or text built in the query | Result sets | Anything |
| Where it runs | XML databases and XQuery processors | Relational databases | Anywhere |
XQuery is not a replacement for a general-purpose language. In practice it handles the data-access and transformation layer, and a host language or the database's own HTTP layer handles the rest.
How XQuery relates to eXist-db
eXist-db is an open-source native XML database, licensed under the LGPL, that stores XML documents and executes XQuery against them. In that setting XQuery is not just a query tool but the application language: you can write queries that read stored documents and return HTML, which is how eXist-db supports full-stack XML web application development.
The project's own materials show this pattern in real deployments. The U.S. Department of State's Office of the Historian uses eXist-db to power a public website where visitors search and browse nearly a hundred thousand archival government documents. The Tibetan Buddhist Resource Center describes holding nearly 10 million scanned pages and over 11,000 Unicode Tibetan texts with online access for over 4,000 users. The University of Victoria Humanities Computing and Media Centre reports using eXist-db across a dozen or more projects. These are document-centric, search-heavy workloads, which is exactly where XQuery plus an XML database fits.
Where to start
- Learn the language basics first: path expressions, FLWOR expressions (
for,let,where,order by,return), and element constructors. These cover most day-to-day queries. - Get a place to run queries. eXist-db is one option; its site provides documentation and downloads, and the download page is the entry point for installing it locally.
- Practice on real XML. Take a small set of documents in a vocabulary you care about (TEI, DocBook, RSS) and write queries that filter and reshape them. This is faster than abstract exercises.
- Move to application patterns once queries are comfortable: returning HTML from queries, and organizing stored documents into collections.
A common sticking point is expecting SQL-style thinking. XQuery works on ordered, nested sequences, so "joining" often means iterating over one document set and looking up related nodes in another, and results keep document order unless you sort explicitly. Another is forgetting that constructed XML and computed values are different things; the curly-brace syntax is what bridges them.