Extensible Markup Language, or XML, is more than a simple syntax for Internet transport. It entails a new way of thinking about information.

Different communities embrace the language for different reasons. Its platform and vendor neutrality make it a natural format for Service Oriented Architectures and Web Services. Its simple syntax is widespread and its schema flexibility makes XML attractive.

A widespread misconception says, "XML is only a syntax." While it's true that the XML 1.0 standard proposed in 1997 was simply a syntax for a file, XML has evolved beyond that humble beginning. This article studies:

• The data model
• The type system and processing languages underlying XML as an information model
• The relationships between components
• The potential impact components have on existing IT architectures
• XQuery, the new declarative XML processing language being standardized by the W3C

An XML processing solution adds various data access APIs specifically designed for XML to existing programming languages. Such APIs are either language-specific like SAX or STAX (for Java) and XMLReader for C# or language-agnostic like DOM. They either view the XML data as a virtual or materialized conceptual tree (DOM) or as a stream of events that can be processed in a pull (STAX) or push fashion (SAX). Despite the widespread use of XML APIs in real-world applications, programming with XML at this low level of abstraction is tedious and poses a large number of performance and productivity problems.

Native XML processing languages, XPath 1.0 and XSLT 1.0, were proposed immediately after XML was standardized. XPath 1.0, made a standard in 1998, has been adopted as the basic language component that allows projection of XML content. XSLT 1.0, standardized in 1999, is a recursive template-based XML transformation language. Projection and transformation are only some of the XML processing needs. So these two languages alone can't satisfy the needs of XML processing.

XQuery, the declarative XML processing language, is a seven-year collaborative effort. It's a set of specifications, each describing a component of a global architecture. To understand XQuery, we need to understand the role of each architectural component and their interoperatation.

XML's abstract data model (XDM) forms the basis of XQuery 1.0. The 1998 XML proposal had one standardized syntax. Since one can't reason with characters, we must use an abstract data model to program this information.

XQuery is a functional language manipulating operation sequences similar to the way a programming language would operate. An XQuery program is composed of a prolog that defines the environment where the main body of the program executes. Its body is simply an expression created by recursive applications of expression constructors, starting with variables and constants. Note that XQuery programs can read existing data and compute new results based on the existing data, but can't modify existing data or modify the environment where they execute. While this is a clear usability limitation, this property ensures that traditional database query optimization techniques remain applicable.

XQuery supports several kinds of expression constructors, such as function calls, conditional expressions, and type switches. Of particular importance are two expression constructors: path expressions, FLWOR (For Let Where Orderby Return and pronounced Flower) and node constructors.

Path expressions allow navigation in a conceptual XML tree and are syntactically consistent with the design of the navigation capability of XPath 1.0. Such navigation lets XQuery explore, the children, the descendants, and the ascendants of a certain node. In addition, the name or type restrictions can be imposed on selected nodes during navigation as well as arbitrary predicates using the path filters.

The FLWOR expression constructor, based on the mathematical principles of monoids, are second-order expressions allowing iteration over a Cartesian product of sequences, filtering based on a where clause, ordering using the orderby clause, and a projection specified using a return clause. Unlike SQL, where Select From Where has a special role in the language, FLWOR expressions are just one way to build expressions in XQuery. XQuery is a fully compositional language in the sense that expressions can be nested arbitrarily in each other with no grammatical restrictions - only type restrictions are imposed.

Besides extracting existing data, XQuery can create new XML data model instances. This is done using the node constructor expressions that can be composed arbitrarily with the other kind of expressions in the language. For each kind of XML node, there's at least one way of building nodes of this kind starting with dynamically computed content. The XML elements have a syntax that's based on the native XML syntax for elements, with the additional ability to invoke dynamic expressions to compute parts of their content.

A rich built-in function library is shared among XPath 2.0, XSLT 2.0, and XQuery. It includes basic functions and frequently used operators. XQuery also allows user-defined functions in the prolog section. Each function definition includes the function name, function argument type declarations, and the expression that computes the result of the function. The body of a user-defined function is an unrestricted XQuery expression. XQuery allows extensibility through external functions that can be implemented in other programming languages and invoked from XQuery.

XQuery's type system is based on XML schema. A document describes rules for static typing of XQuery expressions and the conditions under which a program using the feature should raise type-checking errors. The typing rules are pessimistic in the sense that the type-checking phase of an expression that could raise type errors during the evaluation is required to raise a type checking error. Static typing isn't mandatory but optional in XQuery. Many implementations don't implement it or they implement a proprietary version.

XQuery is a rich XML processing language that supports expression constuctors. The ability to define functions and recursive functions make XQuery a Turing complete language. Originally intended to be a "query" language, in practice XQuery surpassed the original goal; in its current definition it's a general, declarative XML mapping language. Similar to the way SQL can be seen as a declarative way of mapping between the inputs, XQuery can be seen as a declarative mapping language between the input XML data instances and the resulting XML data model instance.

Why have two languages? In practice XSLT 2.0 and XQuery aren't competitive, but complementary ways to process XML data. Both can be applied to the same XML transformation problem, yet there are cases when XSLT is the more appropriate programming paradigm, while in other cases XQuery is. They solve the same problems using different programming paradigms: recursive templates for XSLT and iteration FLWOR for XQuery. Depending on the problem at hand or the programmers' skills, one language can be more appropriate than the other.

There are at least two major advantages to using XQuery over XSLT. XSLT's dataflow analysis is very hard to achieve given the dynamic recursive nature of the language.

An advantage XQuery offers over programming with XML APIs, like DOM or SAX, is the gain in productivity. The XQuery code that performs a certain operation is easier to write and understand than the equivalent low-level API program. XQuery has a lower level of abstraction language with XML APIs that's based on a long-term database lesson: logical/physical data independence is the golden rule in computing. If the physical representation of the data changes (the addition of a new index or a materialized view), the XQuery code simply has to be recompiled in most cases, while it has to be rewritten from scratch if the case uses a specific access pattern via an API.

XQuery's similarity in spirit with SQL is a significant advantage over XSLT, because it facilitates the learning curve of the new language and speeds up its adoption. Not to be overlooked is XQuery's greater potential for automatic optimization. The similarity in spirit with SQL makes immediately applicable almost all the optimization techniques used for optimizing relational queries. Not all such opportunities are exploited in existing XQuery engines, yet the language allows for them and it's expected that implementations will soon exploit such opportunities.

A frequent question concerns the major use-case scenarios for XQuery. In some sense the definition of XQuery as a "query language" is sometimes misleading. XQuery usability goes beyond the typical usage scenarios of the "other" query language: SQL. Unlike a SQL query that's been designed and used only as a server-side query language, XQuery has been designed as a general declarative XML processing language that can be used on persistent or temporary data and on transacted and non-transacted data. Moreover, XQuery isn't intended only for server-side execution, but it's potentially used in all the tiers of a typical architecture.