Re: Regular expression functions (Was: Re: comments on

> I think that in both cases returning different trees would be more
> consistent,

It's consistent with xslt tree creatuion but inconsistent with
side-effect free function semantics which are there at least in part so
that you can optimise and re-order function calls.

f(x) + f(x)

is the same as 2 * f(x)  so long as f isn't doing anything nasty like
incrementing a global variable counting how many times it was called.

It's the same with Xpath functions (and is presumably why document() is
explictly defined to return the same tree if called twice with the same
argument, even if the url that's used is pointing at some dynamic
content).  Here if f is returning a tree (that is, a sequence of one
item, which contains a node) and it's not true that f(x) == f(x)
then it means that an optimiser can't replace x == x by true()
for any expression x. This is the sort of thing that's supposed to be
easier with the stronger typing from Xquery, not harder.

> For example, given the problems that I described about processing x,y
> coordinates as pairs, there's a strong temptation to create pairs of
> coordinates as 'coordinate' elements with 'x' and 'y' attributes,
> rather than a simple sequence of integers. If sequences could be
> nested, I wouldn't feel that temptation.

Yes I agree strongly with this, the no-nesting restriction is probably
the strangest part of Xpath2 and there's no justification given for it in
the drafts as far as I can see. There may well be a justification, but
I haven't seen one in the drafts (not that I've read every page yet).

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list