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.

There are several environments in which XQueryX may be useful:

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 for the proposed syntax.

observed that the says 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. There are many possible ways to define an XML syntax for XQuery. This document specifies two XML Syntaxes for XQuery: the one in and the trivial embedding defined in this section. Of course, XQueries could be expressed in XML Syntax in other ways.

The trivial embedding specified here can be used when an XQuery is exchanged with other entities as XML or embedded in an XML document, and when it is not necessary to communicate the underlying structure of the query. When this alternative is chosen, the XQuery expression is treated as though it were ordinary text.

The trivial embedding defined in this specification requires that the entire query be enclosed within an element named "xquery" in the XQueryX namespace (the "xqx:" namespace prefix is used here only for the purposes of this example), as illustrated here:

XQuery expressions are, for the purposes of this trivial embedding, treated as literal text. Therefore, if the XQuery contains characters that are prohibited in XML text (specifically < and &), they must be "escaped" as character entity references (&lt; and &amp;, respectively) or as numeric character references (for example, &#x3C; and &#x26;, respectively), or they must be enclosed in a CDATA section (for example, <![CDATA[<]] or <![CDATA[&]]). Note that this includes the leading "<" of a CDATA section that appears in the original XQuery expression. In addition, because the sequence of characters "]]>" is always prohibited within element content, it is recommended that instances of > in the original XQuery always be "escaped" (for example, as &gt;, &#x3E;, or <![CDATA[>]]).

or

This limitation may require that user agents scan the XQuery text, escaping such prohibited characters, before transmitting or embedding the XQuery as XML.

The following two more complete examples (which are equivalent to one another and to "for $i in (1 to 5) let $j := 4 where $i < $j return <x><i>{$i}</i></x>") further illustrate the use of the XQueryX trivial embedding.

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 , .