RE: XPath 2.0: Collection-Valued Expressions (Was: Re:

> Thanks (and to Evan) for illustrating this syntax. It's made it clear
> to me that for xf:sum(), xf:min(), xf:max() and xf:avg() you need a
> two-step process - build the new sequence, then use that as the
> argument to the function. If we're allowed to write our own functions
> in XSLT 2.0 then we don't even need extended XPath expressions like
> the above, aside from for concision/readability.
>
> However, I don't think it's a viable approach for functions that need
> to return the original values from the sequence, such as xf:sort() and
> xf:value-distinct.

I agree: if you take a purely functional-programming approach, then these
things require higher order functions. XPath 2.0 is not taking a purely
functional-programming approach; where the required functionality cannot be
provided using "first-order" functions and operators, it is being provided
using special syntax in the language (either in XPath itself, or in
XSLT/XQuery). This certainly includes sorting, grouping, elimination of
duplicates, and projection.

(I'm reporting the current situation here, not expressing any views as to
whether I think it's the best approach. Personally I'm attracted by the
flexibility and composability of higher-order functions, but I don't know
whether they would be asking too much of our target user population. I also
suspect that custom syntax makes life easier for query optimizers.)

The reason for having a sort() function is primarily for sorting a sequence
of simple values, such as numbers, strings, or dates. For sorting a sequence
of nodes, more powerful syntax will usually be needed, such as xsl:sort.

Mike Kay


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