Download XML Prague 2011 Conference Proceedings

Declarative XQuery Rewrites for Profit or Pleasure
solution. In practice, the rule author will need to be responsible for the correctness
of their rules.
Even so, rewrite rules that change semantics and "correctness" can be useful
under certain circumstances. Similar to the use of operator overloading in C++, rewrite rules have potential uses in creating domain specific languages operating
outside the bounds of specified XQuery semantics. Consider the following rewrite:
AddComplex: ~a + ~b
where rw:subtype(~a, 'element(my:complexNumber)') and
rw:subtype(~b, 'element(my:complexNumber)')
-> element my:complexNumber {
element my:real { ~a/my:real + ~b/my:real },
element my:imaginary { ~a/my:imaginary + ~b/my:imaginary }
}
This rewrite rule allows two elements representing complex numbers to be added
together using the regular "+" operator, an operation that should almost certainly
result in an error according to the XQuery specification.
3.1. Normalizing Rewrites
When considering correct rewrite rules, there are appear to be two broad categories
that beneficial rules fall into - normalizing rewrites and optimizing rewrites. XQuery
is a broad, declarative language, and there is often more than one way to write any
given operation. Given that, there is often a need to normalize the types of expressions used into a smaller set of expressions, so that the surface area of the language
is smaller and it is easier to find more generally applicable optimizing rewrites.
The XQuery Formal Semantics [2] defines one set of normalizing rewrites, although it should by no means be considered to be the only set possible. The choice
of post-normalization language often makes a difference to how easy it is to
identify different optimizations.
Consider, for instance, the rewrite rule discussed in Section 2.2 which optimizes
the expression "count(~e) eq 0". In XQuery there are two types of comparison operator, "eq" and "=". The former is a straightforward transitive equality operator operating on singleton items, whereas the latter is existentially quantified and can operate
over sequence operands. This means that the rule matching the "eq" operator will
not automatically match an expression using the "=" operator.
However, a normalizing rewrite can solve this problem:
NormalizeToEQ: ~a = ~b
where rw:subtype(~a, 'item()') and rw:subtype(~b, 'item()')
-> ~a eq ~b
217