The states that The XML Query Language MAY have more than one syntax binding. One query language syntax MUST be convenient for humans to read and write. One query language syntax MUST be expressed in XML in a way that reflects the underlying structure of the query.

XQueryX is an XML representation of an XQuery. It was created by mapping the productions of the XQuery grammar into XML productions. The result is not particularly convenient for humans to read and write, but it is easy for programs to parse, and because XQueryX is represented in XML, standard XML tools can be used to create, interpret, or modify queries.

In this document, examples and material labeled as Note are provided for explanatory purposes and are not normative.

There are several environments in which XQueryX may be useful:

The most recent versions of the XQueryX XML Schema and the XQueryX XSLT stylesheet are available at http://www.w3.org/2005/XQueryX/xqueryx.xsd and http://www.w3.org/2005/XQueryX/xqueryx.xsl, respectively.

XQueryX is an XML representation of the abstract syntax found in Appendix A of . The XQueryX syntax is defined by the XQueryX Schema, which is specified in . The XQueryX semantics are defined by a stylesheet that maps an instance of XQueryX to an instance of XQuery; see .

The main data structure in the XQueryX Schema is the set of types that describe expressions. We have chosen to model expressions using substitution groups, with an "expr" abstract base class and a number of intermediate abstract classes.

Consider the following productions from the abstract syntax:

The following XQueryX Schema definitions reflect the structure of those productions from that abstract syntax:

Since XQuery uses the expression production liberally to allow expressions to be flexibly combined, XQueryX uses the exprWrapper type in embedded contexts to allow all expression types to occur.

Three of following examples are based on the data and queries in the XMP (Experiences and Exemplars) use case in , while a fourth example is based on the data and queries in the NS (Queries Using Namespaces) use case. For each example, we show the English description of the query, the XQuery solution given in , an XQueryX solution, and the XQuery that results from applying the XQueryX-to-XQuery transformation defined by the stylesheet in to the XQueryX solution. That produced XQuery is presented only as a sanity-check — the intent of the stylesheet is not to create the identical XQuery expression given in , but to produce a valid XQuery expression with the same semantics. The semantics of the XQueryX solution are determined by the semantics of the XQuery expression that results from that transformation. The "correctness" of that transformation is determined by asking the following the question: Can some XQueryX processor QX process some XQueryX document D1 to produce results R1, after which the stylesheet is used to translate D1 into an XQuery expression E1 that, when processed by some XQuery processor Q, produces results R2 that are equivalent (under some meaningful definition of "equivalent") to results R1?

Comparison of the results of the XQueryX-to-XQuery transformation given in this document with the XQuery solutions in the may be helpful in evaluating the correctness of the XQueryX solution in each example.

The XQuery Use Cases solution given for each example is provided only to assist readers of this document in understanding the XQueryX solution. There is no intent to imply that this document specifies a "compilation" or "transformation" of XQuery syntax into XQueryX syntax.

In the following examples, note that path expressions are expanded to show their structure. Also, note that the prefix syntax for binary operators like "and" makes the precedence explicit. In general, humans find it easier to read an XML representation that does not expand path expressions, but it is less convenient for programmatic representation and manipulation. XQueryX is designed as a language that is convenient for production and modification by software, and not as a convenient syntax for humans to read and write.

Finally, please note that white space, including new lines, have been added to some of the XQueryX documents and XQuery expressions for readability. That additional white space is not produced by the XQueryX-to-XQuery transformation.

Here is the XML Schema against which XQueryX documents must be valid.

This section defines the conformance criteria for an XQueryX processor (see Figure 1, "Processing Model Overview", in , .

In this section, the following terms are used to indicate the requirement levels defined in . [Definition: MUST means that the item is an absolute requirement of the specification.] [Definition: SHOULD means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.] [Definition: MAY means that an item is truly optional.]

An XQueryX processor that claims to conform to this specification MUST implement the XQueryX syntax as defined in of this specification and include a claim of Minimal Conformance as defined in , . In addition to a claim of Minimal Conformance, it MAY claim conformance to one or more optional features defined in , .