This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Reference to functions (Was: RE: XPath 2.0: Collection-Valued Expressions (Was: Re: XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0))
- To: mhkay at iclway dot co dot uk
- Subject: [xsl] Reference to functions (Was: RE: XPath 2.0: Collection-Valued Expressions (Was: Re: XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0))
- From: Dimitre Novatchev <dnovatchev at yahoo dot com>
- Date: Fri, 7 Sep 2001 21:57:19 -0700 (PDT)
- Cc: xsl-list at lists dot mulberrytech dot com
- Reply-To: xsl-list at lists dot mulberrytech dot com
> > 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