Declarativeness of XQuery

Dear WG,

I think it unfortunate that (the June 2001 draft version of) XQuery is
not completely declarative.  By this I mean that expressions, and in
particular node constructors, can have side effects.  E.g.:

let $x := <foo/> return $x == $x

has the value "true", while

<foo/> == <foo/>

has the value "false".

This also means that:

1) XQuery is not referentially transparent.

2) Constant subexpression elimination and strength reduction type of
optimizations will be harder.

3) Values of XQuery expressions are not simply instances of their types,
because they have this extra node identity property.

4) Rule 10 in FS, Appendix A is incorrect, take (like my example above)
e1 to be "<foo/>" and e2 to be "v == v".

5) An attempt to really define '==' in the formal semantics value
inference rules (instead of just mapping it to a function that is only
vaguely defined, what exactly is "the same application of a node
constructor", particularly for already existing documents ?) will be
quite complicated.

If you really want XQuery to be declarative (as the Requirements state)
I would suggest getting rid of the whole concept of node identity.

Regards,

Bas de Bakker
X-Hive Corporation

Received on Thursday, 9 August 2001 06:23:53 UTC