Abstract

The XML Query (XQuery) language has been designed to query collections of XML documents. It is thus different from XSLT, which primarily transforms one document at a time. However, the core of both languages is XPath 2.0, which means that learning XQuery (and XSLT 2.0) is not very hard when starting with a solid knowledge of XPath 2.0. XQuery's main concept is an expression language which supports iteration and binding of variables to intermediate results. The final result of an XQuery is a tree, which can be serialized in various serialization formats.

XSLT using XPath

XQuery using XPath

XQuery using XPath + Database

XML Syntax

• XML syntax is good (and bad …)
  • XML is well-known and supported by many tools
  • XML is verbose and hard to parse for humans
• XSLT's XML syntax is good (and bad …)
  • it is easy to use for experienced XML users
  • and a nightmare to get used to for XML beginners
  • it can be easily fed to itself for advanced applications (meta-stylesheets)
  • which only advanced XSLT programmers will ever do
• Even XSLT is not completely XMLized
  • XSLT language constructs are XML elements and attributes
  • XPath expressions use their own non-XML syntax (very hard to process in XSLT )
  • XSLT is a compromise between XML and non-XML

XQuery Syntax

• XQuery should become the new query language for data
  • some say for any data (because relational data can be represented as XML anyway)
  • others say for XML data only
  • either way, XQuery will become an important language
• XML syntax has been perceived as something people don't like
  • there is no hard evidence that XML syntax really is an acceptance problem
  • but many people this might be the case for a query language
  • non-XML syntaxes can be more compact than XML syntaxes
• Query language specialists are used to SQL's keyword-based syntax
  • XQuery imitates this approach to make it easier to switch
  • XML shows up anyway because XQuery constructs XML
  • you can't really escape XML when you are working with XML …

XQuery Syntax Example

<bib>
 {
  for $b in doc("http://bstore1.example.com/bib.xml")/bib/book
  where $b/publisher = "Addison-Wesley" and $b/@year > 1991
  return
    <book year="{ $b/@year }">
     { $b/title }
    </book>
 }
</bib>

XQueryX Syntax Example

     <xqx:flworExpr>
      <xqx:forClause>
       <xqx:forClauseItem>
        <xqx:typedVariableBinding>
         <xqx:varName>b</xqx:varName>
        </xqx:typedVariableBinding>
        <xqx:forExpr>
         <xqx:pathExpr>
          <xqx:stepExpr>
           <xqx:filterExpr>
            <xqx:functionCallExpr>
             <xqx:functionName>doc</xqx:functionName>
             <xqx:arguments>
              <xqx:stringConstantExpr>
               <xqx:value>http://bstore1.example.com/bib.xml</xqx:value>
              </xqx:stringConstantExpr>
             </xqx:arguments>
            </xqx:functionCallExpr>
           </xqx:filterExpr>
          </xqx:stepExpr>
          <xqx:stepExpr>
           <xqx:xpathAxis>child</xqx:xpathAxis>
           <xqx:nameTest>bib</xqx:nameTest>
          </xqx:stepExpr>
          <xqx:stepExpr>
           <xqx:xpathAxis>child</xqx:xpathAxis>
           <xqx:nameTest>book</xqx:nameTest>

XPath and XQuery

• Every XPath expression is a valid XQuery expression
  • if you are very good at XPath, you can reuse a lot of you knowledge
  • XQuery gives alternative expressions and missing functionality
• XPath is a language for selecting nodes in existing documents
  • XPath has no language features to construct new XML trees
  • re-ordering a tree (i.e., sorting) also involves constructing a new tree
• XPath is more relevant for XSLT/XQuery experts
  • advanced XPath concepts will take you very far
• XQuery expressions can be used to simplify XPaths
  • in the same way as in XSLT, there is a trade-off in complexity between the languages

XPath vs. XQuery

• Choosing a certain style can be a question of taste

//reference[starts-with(date/@value, '2000')]/title

  for $ref in //reference
   where starts-with($ref/date/@value, '2000')
   return $ref/title

XQuery's Central Construct

• FLWOR is pronounced flower (it went through several syntax iterations)
  • must have at least one for or let
  • may have where and order by
  • must have return
• Iteration over a sequence of items
  • similar to for-each or similar loop constructs
  • works slightly differently because of XQuery's Processing Model
  • where is comparable to XPath predicates

FLWOR – For

• Iteration over an input sequence
  • for each item in the input sequence, a result is calculated
  • the result of the for clause is the concatenation of all these results
• If there is only a return, it is the same as XPath's Iterations

for $i in (1 to 10) return $i * $i

<titles>
 {
  for $ref in //reference/title/text()
   return <title> { $ref } </title>
 }
</titles>

FLWOR – Let

• Declares a variable and assigns a value to it
  • may use previously assigned variables
  • can be used any number of times mixed in any order with for clauses

<titles>
 {
  let $title := //reference/title/text()
   return <title> { $title } </title>
 }
</titles>

<titles>
 {
  for $ref in //reference
   let $title := $ref/title/text()
   return <title> { $title } </title>
 }
</titles>

For & Let

• Variables in most cases are used for convenience
  • they avoid repeating things and often result in a more structured query expression
  • writing XQueries should not be an exercise in minimizing the character count
• For single items, for and let can be interchanged (handy for XPath)

let $x := 'whatever' return …

for $x in 'whatever' return …

FLWOR – Where

• Filtering the items from for and let clauses
  • there may be at most one where clause in a FLWOR expression
  • it has to appear after all for and let clauses
• A where clause almost always uses a variable
  • they act as filters of the sequences generated by for clauses
  • they act based on the value of the items in that sequence

<titles>
 {
  for $ref in //reference
   where starts-with($ref/date/@value, '2000')
   return $ref/title
 }
</titles>

• Predicates in XPath expressions do the exact same thing
  • but predicates can only be applied to nodes
  • SQL users find the where approach easier to understand

FLWOR – Order by

• FLWOR results are evaluated in the order resulting from the for clauses
  • for nested clauses, this means a nested evaluation of for clauses
  • this will often reflect the document order (depending on the for XPaths)
• Any order other than this has to be achieved by sorting
  • multiple sort keys can be specified separated by commas
  • sorting can be done ascending or descending

<names>
 {
  for $person in //person
   let $given := $person/givenname/text()
   let $sur := $person/surname/text()
   order by $given ascending, $sur descending
   return <name> { $given, ' ', $sur } </name>
 }
</names>

FLWOR – Return

• Required in every FLWOR expression
• Constructs new nodes and fills them with values
  • element constructors can be used to generate elements
  • attribute constructors can be used to generate elements

<names>
 {
  for $person in //person
   let $given := $person/givenname/text()
   let $sur :=  $person/surname/text()
   order by $given ascending, $sur descending
   return <name given="{ $given }" sur="{ $sur }"/>
 }
</names>

Tuple Stream

• FLWOR expressions are the central expression producing results
  • nested for loops turn sorting into a non-trivial task
  • the concept of a tuple stream formally defines FLWOR evaluation
• Each FLWOR expression is generating a tuple stream
  • for and let generate a sequence of bound variables, the tuple stream
  • where acts as a filter testing tuples against a constraint
  • order can be used to reorder the (possibly filtered) tuple stream
  • result is evaluated once for each tuple in the filtered, reordered stream
  • the result of the expression are the concatenated results of all result evaluations

Serialization

• XQuery creates a XDM instance as a result
• XDM instances are sequences of items
  • items can be atomic values
  • items can be nodes which are nested to form trees
• XQuery itself is not concerned with how to serialize XDM instances
  • the language works on XDM and produces XDM
• XSLT 2.0 and XQuery 1.0 Serialization defines the serialization of XDM instances
  • the specification can be reused for XSLT 2.0 and XQuery 1.0
  • if other serializations are required, this does not affect the core standards
  • currently supported output methods are XML, XHTML, HTML, and Text
• Text output means that non-markup structures can be created directly

XPath in AJAXLink

• XQuery and XSLT are often regarded as competitors
  • for pure server-side scenarios, this might be true
  • in distributed scenarios, both languages may co-exist
• Large linkbases need to be maintained by a database
  • document-based in-memory processing will only work for moderately sized linkbases
  • XML databases provide the features required for handling large volumes of data
• On the client side, relatively small numbers of links can be expected
  • the system design must ensure that there is a limit to the number of received links
  • the links can be delivered as an XML document
• Rendering of XLinks could be based on XSLT code
  • Sarissa provides cross-browser support for XSLT
  • well-designed XSLT could be the foundation for linklets (customized rendering)

XQuery and XSLT

Linklets

Clearer Queries

• XPath is too condensed for many users
• XQuery provides a less compact and easier accessible syntax
• XQuery provides features which are nor part of XPath