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@xxxxxxxxx> Date: Fri, 7 Sep 2001 21:57:19 -0700 (PDT) |
> > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] String parsing in XSLT/XP, Sullivan, Dan | Thread | Re: [xsl] Reference to functions (W, Jim Melton |
Re: [xsl] Trying to find a working , G. Ken Holman | Date | RE: [xsl] IE6, Joshua Allen |
Month |