Reference to functions (Was: RE: XPath 2.0: Collection

> > One thing that seems to be missing from the F&O WD is support for
> > XPath 2.0 Requirement 2.5 "Should Support Aggregation Functions Over
> > Collection-Valued Expressions".
> >
> > There are frequently cases where it would be useful to evaluate an
> > expression to use for calculating sums, maxima, minima, averages, sort
> > values and so on. We currently have to use case-specific templates or
> > something along the lines of Dimitre's generic templates to do this
> > kind of thing.
> 
> The current intention is to do this with special syntax, not with a
> higher-order function; this puts it outside the scope of the F&O document.
> As you'll see from the published data model, there is no current intention
> to support functions or expressions as a data type in the language.

So, one significant and useful feature has been ignored... 

> So there's likely to be syntax akin to XQuery's

> sum(for $i in //item return $i/@price * $i/@qty)

I find this a definite step backawrds from the concise and compact syntax of XPath
1.0. 

"for $i in //item return $i/@price * $i/@qty" 

is not an expression -- it is a ***procedural statement***.

This is clumsy and much more unreadable than

xf:sequence(//item, @price * @qty)

Going along on this line we'll no longer write what used to be XPath expressions.
Instead, we will be writing ***programs*** in another language (why not call it
COBOL 2003) and we will pretend that such a program is (a part! of) an XPath 2.0
expression.


> We've also been toying with extending path expressions:
>
> sum(//item/(@price*@qty))
> 
> but that causes backwards-compatibility difficulties that we haven't solved
>yet.
>

So the only neat solution left will be introducing "generic functions" through just
two new functions:

xf:function($function-ref, param?)

and

xf:function-reference(QName)

This is more general than just allowing "expression objects", is much more concise
and readable than COBOL 2003, does not pose backwards-compatibility problems.

And, as argued elsewhere, generic templates/functions make it possible to achieve
true run-time polymorphism.

> > Tied in with this is the oft-requested functionality of being able to
> > dynamically evaluate a string as an XPath. Put these together, and an
> > expression data type along the lines of the one in Saxon seems like a
> > good idea.
> 
> There is an aim to have a much more rigorous type system in XQuery and XPath
> 2.0 than is present in XPath 1.0, with much more scope for static type
> checking and optimization. Unfortunately this makes the addition of dynamic
> features to the language, such as the ability to create expressions from
> strings, rather more difficult. Although this feature is much wanted, there
> was an explicit decision not to include it in the XSLT 2.0 or XPath 2.0
> requirements.

This is just a strong confirmation that generic templates will remain for a long
time the only way to accomplish this simple, well-defined and necessary
functionality (e.g. as described in Jeni's examples) without having to resort to
extension functions.

Cheers,
Dimitre Novatchev.

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

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