Abstract

XQuery has been built on top of XPath 2.0, which means it uses the same foundation as XSLT 2.0. Both languages have a large overlap, and according to personal preferences and the XML task, one language may be preferred over the other. Features such as user-defined functions and schema-awareness bring XQuery even closer to XSLT 2.0, making the decision to choose one over the other mostly a question of personal preference.

Outline (XQuery & XSLT)

XQuery & XSLT [8]
More XQuery Details [3]
User-Defined Functions [2]
Conclusions [1]

XPath 2.0 vs. XSLT 2.0

XPath 2.0 is powerful but incomplete
- cannot create nodes (only selection of existing nodes)
- does not support user-defined functions
- no support for grouping
- no support for sorting
XSLT 2.0 extends XPath 2.0 with additional features
XSLT 2.0 adds more features which were missing in XSLT 1.0
- analyze-string for processing strings
- format-date() and format-number() for formatted values
- for-each-group for easy grouping and access to group information
- Keys for optimizing and organizing access to nodes
XSLT's functional programming model has nothing to do with XPath

Turing Completeness

XSLT 2.0 and XQuery are both Turing complete
- any algorithm computing output from input can be implemented
- Turing completeness says nothing about how appropriate a language is for a task
Choosing between XSLT 2.0 and XQuery is a matter of taste and politics
- the functional style of XSLT is hard to get used to
- most people feel more comfortable with the more traditional design of XQuery
- providing and using one of the languages is a long-term decision
Choosing between XSLT 2.0 and XQuery also depends on the task
- simple extraction of XML content is mostly XPath 2.0 anyway
- generating rigid schemas from XML sources works well in both languages
- document processing (Mixed Content) is better done with XSLT 2.0
- large scale data processing is better done with XQuery

XSLT Assumptions

Transformations process the complete input
- the XSLT Processing Model works well for processing most nodes
- Built-In Templates can be used for applying default transformations
XSLT users are highly skilled in XML
- XSLT's XML syntax is hard to learn and use for non-XML experts

XQuery Assumptions

Queries only extract selected part of the input
- there is no default behavior
- understanding the control flow in XQuery is much easier than in XSLT
XQuery authors are not necessarily XML experts
- input and output in many cases will be XML
- the language syntax should be as human-oriented as possible

XSLT BlogXML Processor

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:template match="/">
  <html>
   <body>
    <table border="1" cellpadding="20">
     <xsl:for-each select="//post">
      <tr>
       <td><a href="../img/{image/@src}.jpg"><img src="../img/{image/@src}-small.jpg"/></a></td>
       <td>
        <h2><xsl:value-of select="format-date(@date, '[F] [MNn] [D], [Y]')"/>: <xsl:value-of select="title"/></h2>
        <p><xsl:value-of select="text"/></p>
       </td>
      </tr>
     </xsl:for-each>
    </table>
   </body>
  </html>
 </xsl:template>
</xsl:stylesheet>

XQuery BlogXML Processor

<html>
 <body>
  <table border="1" cellpadding="20">
   { for $post in //post return
    <tr>
     <td><a href="../img/{ $post/image/@src }.jpg"><img src="../img/{ $post/image/@src }-small.jpg"/></a></td>
     <td>
      <h2> { local:format-date($post/@date) }: { $post/title/text() } </h2>
      <p> { $post/text/text() } </p>
     </td>
    </tr>
   }
  </table>
 </body>
</html>

2-Step vs. 1-Step

Web applications often are built as multi-tier applications
REST services provide the interface to the data
- they provide access to resources which are managed by the service
- in many cases the data representation is some XML format
Interfaces than use that data in various ways
- UIs may present it in HTML
- APIs may present it in some API-specific way (e.g., import/export)
XQuery is well-suited to retrieve data from an XDBMS
XSLT is well-suited to transform data to a specific presentation format

Web App with XQuery & XSLT

Web Application Tiers with XQuery and XSLT

Outline (More XQuery Details)

XQuery & XSLT [8]
More XQuery Details [3]
User-Defined Functions [2]
Conclusions [1]

Comma Operator

Constructing sequences from separate expressions

<a>123</a>, <b>456</b>

doc("books.xml")//author, doc("books.xml")//title

Parentheses must be used to group expressions correctly

for $b in doc("books.xml")//book return   $b/title, $b/author

for $b in doc("books.xml")//book return ( $b/title, $b/author )

Whitespace in XQuery

XQuery distinguishes three kinds of whitespace
- ignorable whitespace occurring between syntax terminals (e.g., keywords)
- boundary whitespace occurring between tags and/or enclosed expressions
- literal whitespace occurring inside literals
boundary-space controls the interpretation of boundary whitespace
- strip declares boundary whitespace to be insignificant
- preserve declares boundary whitespace to be significant

declare boundary-space strip;
let $a := "Bob Glushko"
return
  <book>
    <title>Document Engineering</title>
    <author> { $a } </author>
  </book>

Constructors

XQuery allows literal XML or computed constructors

Literal XML are called direct constructors

<book>
  <title>Document Engineering</title>
  <author>Bob Glushko</author>
  <price currency="USD">29.99</price>
</book>

Computed Constructors can be used for calculating names

element "book" {
  element "title" { "Document Engineering" },
  element "author" { "Bob Glushko" },
  element "price" {
    attribute "currency" { "USD" },
    29.99
  }
}

XSLT has the same concepts (Literal Result Elements and element)

Outline (User-Defined Functions)

XQuery & XSLT [8]
More XQuery Details [3]
User-Defined Functions [2]
Conclusions [1]

Reusable code in XQuery

Named units of XQuery code
Zero or more input parameters (type information is optional)
Produces a result (type information is optional)
Function body is an XQuery expression
- there is no explicit return statement
- the return of a FLWOR expression may take over that role
a predefined local namespace prefix avoids namespace inflation

declare function local:onetwothree() as xs:integer+ { (1, 2, 3) };

Local Function

declare function local:format-date($date) { string($date) } ;

<html>
 <body>
  <table border="1" cellpadding="20">
   { for $post in //post return
    <tr>
     <td><a href="../img/{ $post/image/@src }.jpg"><img src="../img/{ $post/image/@src }-small.jpg"/></a></td>
     <td>
      <h2> { local:format-date($post/@date) }: { $post/title/text() } </h2>
      <p> { $post/text/text() } </p>
     </td>
    </tr>
   }
  </table>
 </body>
</html>

Outline (Conclusions)

XQuery & XSLT [8]
More XQuery Details [3]
User-Defined Functions [2]
Conclusions [1]

XQuery vs. XSLT

XQuery is a complete programming language
XSLT can do everything XQuery can and vice versa
Choosing one over the other depends on task and taste
REST scenarios have good places for both languages

XML Query (XQuery) – Part II

XML Foundations (INFO 242)

Erik Wilde, UC Berkeley School of Information
2007-11-15

Abstract

Outline (XQuery & XSLT)

XPath 2.0 vs. XSLT 2.0

Turing Completeness

XSLT Assumptions

XQuery Assumptions

XSLT BlogXML Processor

XQuery BlogXML Processor

2-Step vs. 1-Step

Web App with XQuery & XSLT

Outline (More XQuery Details)

Comma Operator

Whitespace in XQuery

Constructors

Outline (User-Defined Functions)

Reusable code in XQuery

Local Function

Outline (Conclusions)

XQuery vs. XSLT

XML Query (XQuery) – Part II

XML Foundations (INFO 242)

Erik Wilde, UC Berkeley School of Information2007-11-15

Abstract

Outline (XQuery & XSLT)

XPath 2.0 vs. XSLT 2.0

Turing Completeness

XSLT Assumptions

XQuery Assumptions

XSLT BlogXML Processor

XQuery BlogXML Processor

2-Step vs. 1-Step

Web App with XQuery & XSLT

Outline (More XQuery Details)

Comma Operator

Whitespace in XQuery

Constructors

Outline (User-Defined Functions)

Reusable code in XQuery

Local Function

Outline (Conclusions)

XQuery vs. XSLT

Erik Wilde, UC Berkeley School of Information
2007-11-15