15.8.1.Types of XQuery Expressions
The current draft of XQuery lists 10 groups of XQuery expressions:
-
Primary expressions, including literals, variable references and function calls.
-
Path expressions, including all XPATH 1.0 expressions and a "pointer operator".
-
Sequence expressions.
-
Arithmetic, comparison and logical operators.
-
Element constructors, which allow you to create new element nodes with specified names, lists of attributes and lists of children.
-
FLWR (FOR-LET-WHERE-RETURN) expressions, which allow you to create variables for intermediate results and to transform sequences of items on a per-item basis.
-
Ordered and unordered expressions to force some sorting of intermediate results or to prevent the XQuery processor from making redundant sorting.
-
Control expressions, such as IF.
-
Quantified expressions: SOME and EVERY.
-
Expressions that test or modify data types.
Not all groups of expressions are implemented. In some groups, not all kinds of clauses are implemented.
In addition to the standard, Virtuoso supports special cases of FLWR expressions to deal with XML views:
Primary Expressions
XQuery processor uses 32-bit integers on 32-bit platforms and 64-bit integers on 64-bit platforms. Similarly, the scale and precision of floating-point operations may vary from platform to platform.
Note that string literals are handled differently in XPath 1.0 and XQuery. "Ben "amp; Jerry"apos;s" denotes the string "Ben " Jerry's" in XQuery and the string "Ben "amp; Jerry"apos;s" in XPath.
Path Expressions
Any XPath 1.0 expression is a valid XQuery 1.0 path expression,
which the Virtuoso XQuery processor supports. When invoked from the
XQuery context, the XPath Processor works in accordance with XSLT
rules. There are two major differences between standalone and
XQuery/XSLT path expressions. First, the meaning of non-qualified
name used as NameTest criterion, as described below. Second, the
data type used for attributes varies. In XPath or XQuery mode, if a
value is calculated by an attribute::
axis, it is of type
attribute entity
; in
standalone XPath, the string value of the attribute is used
instead.
As specified in the XQuery 1.0 standard, a node-set returned by an XPath expression may be used as a sequence of items, where every node of that node-set becomes an item of the sequence. The opposite is not true, however. Not every sequence may be converted into a node-set, even if it is a sequence of nodes. If XPath starts from a function which returns a sequence, an error message "Context node is not an entity" is returned. Fortunately, a variable of type
sequence
may be used as a node-set if all items of the sequence are nodes.
Obsolete drafts of W3C specification contains description of
"pointer operator". Virtuoso continues to support this operator to
provide backward compatibility. XQuery processor needs DTD data
associated with the XML document in question to distinguish ID
attributes from other sorts of attributes and to bookmark elements
that have ID locations. For more details, see the description of
id()
XPATH function. This function uses same
DTD data for same purposes, so for any given document, either both
id()
and "pointer operator" are
applicable or both does not work.
Sometimes the "Context node is not an entity" error is signalled if the beginning of the XPath expression is surrounded by parenthesis, even if the expression works fine without these parenthesis. This happens because "(...)" is an "append" operator in XQuery, not just a way to group subexpressions. "append" converts a node-set into a sequence even when it is called with a single argument - that is, without commas inside "(...)". This sequence cannot be used as input for the rest of the XPath expression.
As an syntax extension, special notation of QNames is added and can be used, e.g., in NameTest. An expanded name can be surrounded by delimiters (! and !), like (!http://www.example.com:MyTag!) and this syntax allows names that contain otherwise prohibited characters. This syntax is also useful when the text of the query is generated by software.
Note that the NameTest that consists of an unqualified name has different meanings in Virtuoso XPath and in XQuery. In XPath, NameTest "sample-tag" means "any element whose local-name is equal to sample-tag". In XQuery, the same test means "any element without namespace-uri whose local-name is equal to sample-tag".
Sequence Expressions
XQuery sequences are supported not only in XQuery but can also be handled in XPath and XSLT. When the XQuery processor is invoked from SQL and a sequence is returned to the caller, the sequence is automatically converted into a vector of its elements.
Virtuoso supports all sequence operations listed in current W3C paper plus deprecated operations BEFORE and AFTER.
The sequence
concatenation
operator is available in XPath and XSLT
as the append()
function. In
addition, the tuple()
function is
available to get the first items of every given argument sequence
and return the sequence of these items.
XQuery operators UNION, INTERSECT, EXCEPT are available in XPath
and XSLT as functions union()
, intersect()
and except()
.
Arithmetic, Comparison and Logical operations
Virtuoso shares the implementation of basic arithmetic and
comparison operations between XPath, XQuery, XSLT, SQL and
Virtuoso/PL processors, so type casting, scale and precision of
calculated values are identical across the system. All operators
are available in XQuery, in addition, << and >>
operators are available in XPath and XSLT as is_before()
and is_after()
built-in functions.
Element Constructors
Virtuoso XQuery supports all XQuery 1.0 direct constructors. Previous versions of W3C draft contained the syntax for placing calculated content into the opening tag of direct element constructor, such as
<{concat("calculated-", "element-name")} {concat("calculated-", "attribute-name")}={concat("calculated-", "attribute-value")}>...</>
. Thus name of element or attribute, or a value of an attribute
can be calculated dynamically. This syntax is still supported. The
create-element()
XPath function is implemented to make this functionality available
in XPath. Additionally, a special function create-attribute()
may be used to create a
new dynamic attribute entity with value and name calculated, this
works similarly to xsl:attribute XSLT instruction.
Similarly, create-comment()
, create-element()
and create-pi()
mimics
other XQuery direct constructors in XPath and XSLT.
The XQuery specification states that when sequence of atomic values is converted into content of an element constructor, whitespace character is inserted between adjacent values.
Unlike previous versions of Virtuoso, current XQuery syntax allows you to use "pure XML notation" inside element constructors. Thus there is no strict need to write 'constant' expression
<emp empid="12345"><name>John Smith</name><job>Bubble sorter</job></emp>
as it is dynamically calculated text, like
<emp empid="12345"><name>{'John Smith'}</name><job>{'Bubble sorter'}</job></emp>
It is still may be useful to write 'constant' expression in the old way. This artificial restriction simplifies finding syntax errors, because there are syntactically wrong expressions that are still correct "pure XML notation." Alternatively, CDATA sections also may be used to make it obvious that the string is a constant, not an expression with forgotten braces around it:
<emp empid="12345"><name><![CDATA[John Smith]]></name><job><![CDATA[Bubble sorter]]></job></emp>
The current version of Virtuoso does not support the new XQuery syntax for dynamic constructors.
FLWR Expressions
FLWR expressions are fully supported by Virtuoso XQuery.
Moreover, for()
and let()
XPath functions are implemented to make
this functionality available in XPath and XSLT. In addition,
assign()
and progn()
functions are available to deal with
extension functions, especially when extension functions are called
for their side effects.
A special xmlview() function allows very efficient access to SQL data from XML views.
Previous XQuery specifications used "sort by" instead of "order by". The difference is that "sort by" was applicable to the final results of the FLWR statement made by RETURN clause whereas "order by" reorders input data for RETURN. Thus, "order by" can sort outputs using data that do not appear in the final result. E.g., an expression can collect items, "order" them by category and title but output only title and price. This was much harder in previous versions of XQuery because it was necessary to prepare an intermediate result that contained title and price and category, then do "sort" by category and title then use one more FLWR expression to form a result that is free from redundant data about category.
Nevertheless, Virtuoso supports both "sort by" and "order by", to keep backward compatibility. Moreover, "sort by" operator can be freely used with no relation to any FLWR subexpression. Typical use of such a simplified notation is
<hit-list>{//track[@rating] sort by (@rating descending)}</hit-list>
instead of portable
<hit-list>{for $t in //track[@rating] order by $t/@rating descending return $t}</hit-list>
Ordered and Unordered Expressions
The current version of Virtuoso does not use ordered/unordered hints. Everything is calculated ordered. This will change in the future but it is not advisable to place "unordered" hints for future use because there's no way to validate these hints. It is better to place appropriate comments but not hints.
Control Expressions
The if()
special function mimics the XQuery
operator for use in XPath and XSLT. Functions and()
and or()
are also control expressions because
they calculate arguments in strict left-to-right order and may omit
the calculation of some results.
Quantified Expressions
Both the SOME
and
EVERY
operators are
implemented. The some()
and every()
XPath functions are implemented to
make this functionality available in XPath and XSLT.
Expressions That Test or Modify Data types
The operators IS
,
CASTABLE
, CAST
, TREAT
, TYPESWITCH
and VALIDATE
are not implemented.
FOR Clause Expressions With xmlview() Function
XML views can be queried using FOR Clause from FLWR expressions.
The xmlview()
function
allows XML views to be accessed as if they were XML documents.
XPath expressions beginning with the xmlview()
function will be translated into SQL
statements to avoid redundant data access and to avoid creating a
whole XML tree.