Notes on XQuery to XSLT

1 Notes

XQuery is essentially a profile of XSLT, using a non-XML syntax and omitting xsl:apply-templates, xsl:for-each-group and xsl:analyze-string. Unfortunately however it isn't defined that way and so there are several awkward cases where the mapping from one to the other is harder than one would like. In most cases xq2xsl does (I hope) produce equivalent expressions, but sometimes they are not the most natural XSLT constructs.

2 Copying Namespace Nodes

Considering how close XQuery and XSLT are in most other respects, the two systems differ by a remarkably large amount in their handling of namespace nodes.

declare variable $x := <x xmlns:preserve="preserve"><z/></x>;
declare variable $y := <y xmlns:inherit="inherit"><z xmlns:a="a"/>{$x}</y>;

<a>{
for $n in in-scope-prefixes($y/z) order by $n return $n
  }|{
for $n in in-scope-prefixes($y/*/*) order by $n return $n
}</a>

declare copy-namespaces no-preserve,no-inherit;
declare copy-namespaces preserve,no-inherit;
declare copy-namespaces no-preserve,inherit;
declare copy-namespaces preserve,inherit;

<a>a inherit xml|xml</a>
<a>a inherit xml|preserve xml</a>
<a>a inherit xml|inherit xml</a>
<a>a inherit xml|inherit preserve xml</a>

3 White Space

This processor defaults to stripping boundary space, however if preserve is specified in the prologue all boundary space text nodes are copied to xsl:text elements in the generated stylesheet, and so produce space in the result of running the query.

The only other issue of note regarding white space is the white space is added between items of a sequence but not between adjacent enclosed expressions.

<a>{1,2}{3}</a>

This produces:

<a>1 23</a>

where a space has been added between 1 and 2, but not between this sequence and the 3 in the sequence generated by the next contained expression.

XSLT has an almost identical rule for attribute value templates, but doesn't really have an analogue of contained expressions for element content. xq2xsl currently generates the following, where an empty text node generated by <xsl:text/> is inserted after each contained expression, which prevents white space being inserted.

         <xsl:element name="a">
            <xsl:sequence select=" 1 "/>
            <xsl:sequence select=" 2 "/>
            <xsl:text/>
            <xsl:sequence select=" 3 "/>
            <xsl:text/>
         </xsl:element>

4 typeswitch

XQuery for some reason doesn't have a general multi-way conditional statement, but does have one restricted to testing the type of an expression. xq2xsl maps typeswitch to xslt's xsl:choose expression, testing on the value of "instance of" expressions. I need to check if this fully captures the semantics of typeswitch, especially the rules as to which errors a system may, or may not, raise in branches that are not executed. (It is probably as close as you can get in xslt anyway, but any differences will be documented here).

  typeswitch (2)
  case $zip as element(*)
       return 7
  case $postal as element(ll )
       return 8
  default $x return 9

  <xsl:variable as="item()*" name="xq:ts" select="( 2 ,())"/>
  <xsl:choose>
    <xsl:when test="$xq:ts instance of  element(  * )">
        <xsl:variable as=" element(  * )" name="zip" select="$xq:ts"/>
        <xsl:sequence select=" 7 "/>
     </xsl:when>
     <xsl:when test="$xq:ts instance of  element(  ll )">
        <xsl:variable as=" element(  ll )" name="postal" select="$xq:ts"/>
        <xsl:sequence select=" 8 "/>
     </xsl:when>
     <xsl:otherwise>
        <xsl:variable as="item()*" name="x" select="$xq:ts"/>
        <xsl:sequence select=" 9 "/>
     </xsl:otherwise>
  </xsl:choose>

The spurious trailing ",()" in the definition of the main variable xq:ts whose type is to be tested is there to ensure that the XSLT compiler does not statically determine its type (which would allow it to raise static errors on branches of the xsl:choose that could not arise). A smarter XSLT compiler would require more obfuscation here, or a translation with a schema-aware XSLT engine could perhaps detect the static type of the expression and omit any branches of the xsl:choose that could error in that case.

5 FLWOR: order by

The order by clause in a FLWOR expression is the one XQuery feature that does not easily translate to XSLT. This is essentially because it doesn't easily fit in the XQuery/XPath data model as its natural semantics requires nested sequences (called tuples in the XQuery documentation) but XPath sequences can not contain sequences, only atomic values. The XQuery Formal semantics also explictly omits to give semantics to Order By for the same reason.

The xq2xsl translation does (baring bugs) provide a full translation of a FLWOR expression into XSLT, however as translation of the most general case is rather verbose, the system detects some special cases and translates them more directly. These special cases will be discussed first.

for $i in $is,  $j in $js
order by f($i,$j)
return
g($i,$j)

let $ci :=count($is) return
let $cj :=count($js) return
for $n in (0 to $ci * $cj)
let $i :=$is[$n  mod $ci)+1]
let $j := $js[($n idiv $ci) +1]
order by f($i, $j)
return
g($i,$j)

 for $i in $is,
 $j in F($i)
 order by f($i,$j)
 return
 g($i,$j)

let $one := (
 for $i at $ip in $is,
 $j at $jp in F($i)
 return
 encode($ip,$jp)
)
 return

 for $z in $one
 let $indexes:=decode($z)
 let $ip:=$indexes[1]
 let $i:= $is[$ip]
 let $jp:=$indexes[2]
 let $j:= (F($i))[$jp]
 order by f($i,$j)
 return
 g($i,$j)

6 Current Node

The major difference between an XQuery For expression in one variable, and an xsl:for-each is that the xsl:for-each changes the current item (.) to be the current item in the sequence being processed,whereas a FLWOR expression never changes the current item.

A simple example:

for $i in (1,2,3)
return
$i

This is encoded as:

   <xsl:variable name="xq:here" select="."/>
   <xsl:for-each select="( 1 , 2 , 3 )">
      <xsl:variable name="i" select="."/>
      <xsl:for-each select="$xq:here">
         <xsl:sequence select="$i"/>
      </xsl:for-each>
   </xsl:for-each>

The xq:here variable stores the current item before the For expression, and restores it inside the loop.

The main complication is that the current item is not always defined, but there is no test you can do within XSLT to check if it is defined, and if is not defined the above generates an error on the first line as the expression . generates an error in that case.

In XSLT the current item only becomes undefined in a function body, which isn't so bad as this case can be statically detected and it would be possible to avoid setting/restoring the current item in that case, however a harder case is the initial context, this is set (or not) outside the query and so there is no way of knowing if the current item will be set.

The solution taken here is that xq2xsl always ensures that there is a current item: The implicit initial context is never used, and instead any initial context has to be passed in as the parameter "input". (This name may be changed to the converter's own xq: namespace to avoid possible clash with any external variable named input in the query being converted.) If $input is not set it takes a default value (the integer 1). I believe this behaviour is conformant as an XQuery processor has pretty wide latitude over how the initial context is set up. So the initial template of an xq2xsl derived stylesheet always looks like this:

   <xsl:param name="input" as="item()" select="1"/>

   <xsl:template name="main">
      <xsl:for-each select="$input">
...
      </xsl:for-each>
   </xsl:template>

7 Built in types

Both XQuery and XSLT support two levels of support for schema types. A full processor can handle schema import and user defined types, however a basic processor can not. Unfortunately the conformance levels are not aligned. A Query processor even at the basic level of conformance has access to all the built in schema types, which means that they can be used in sequence type expressions as as constructor functions. A Basic XSLT processor on the other hand only has access to the primitive types (and xs:integer) other built in derived types are not available.

There is essentially nothing that can be done about this. The stylesheet has some experimental support to change any reference to a built in schema derived type to the nearest base type that is supported by a basic XSLT processor. This will allow queries to run without error and in many cases with acceptable results, however in some cases this will produce incorrect results and this translation perhaps should be turned off by default. (Currently it is turned on if the XSLT processor executing the conversion is not schema-aware.)

8 Options and Extensions

XQuery options and extensions are each mapped to XSLT extension elements in the xq2xml namespace (java:Xq2xml). In practice a system might want to augment the stylesheet with additional templates mapping these constructs to system-specific constructs.

declare option a "b";

<x>
{(# yyy one #)(#yyy two #) {1,2}}
</x>

is translated to:

...
   <xq:option name="a">b</xq:option>
...
   <xsl:template name="main">
      <xsl:for-each select="$input">
         <xsl:element name="x">
            <xq:extension>
               <xq:pragma name="yyy"> one </xq:pragma>
               <xq:pragma name="yyy"> two </xq:pragma>
               <xsl:fallback>
                  <xsl:sequence select=" 1 "/>
                  <xsl:sequence select=" 2 "/>
               </xsl:fallback>
            </xq:extension>