Subject: Re: XPath 2.0: Collection-Valued Expressions (Was: Re: [xsl] XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0) From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Sat, 8 Sep 2001 09:59:05 +0100 |
Hi Mike, > So there's likely to be syntax akin to XQuery's > > sum(for $i in //item return $i/@price * $i/@qty) > > 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. 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. Say you want to get the people with a unique combination of first and last name. If you did: xf:value-distinct(person/(xf:concat(name/last, ',' name/first))) then you would get the distinct combinations of the first and last names, not the person elements. It's even more problematic with xf:sort(), I think, but I find it hard to see the rationale behind xf:sort() anyway given that we have xsl:sort in XSLT. Would I be correct in thinking that the for/in/return above is a FLIR expression and that the first syntax also introduces variable assignment within XPath expressions? I share Dimitre's fear that XPath 2.0 will become a new programming language rather than a simple expression syntax, especially where the functionality of the new syntax mirrors something that already exists in XSLT 2.0. The second syntax seems much more compatible with the division between XPath and XSLT as I understand it. > 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. Oh, OK, I didn't realise. Guess it's our fault for letting the multiple requests for dynamic evaluation and its inclusion in several XSLT processors speak for themselves rather than making a formal noise about the requirement. Can I request now that it's on the requirements list for XPath 3.0 (assuming we get that far)? On the subject of typing, when I first read the constructor/cast operations described in the F&O WD, I was concerned that this would mean we would have to write things like: cast as string( xf:floor(cast as double( xf:substring-after(cast as string(@price), '$'))))" /> rather than: string(floor(substring-after(@price, '$'))) Can you (or someone) reassure me that there will still be automatic conversions between value types such that we won't have to be casting/constructing specific data types all over the place? Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XPath 2.0: Collection-Valued Ex, Michael Kay | Thread | RE: XPath 2.0: Collection-Valued Ex, Michael Kay |
Re: [xsl] XQuery 1.0 and XPath 2.0 , Kurt Cagle | Date | Re: [xsl] String parsing in XSLT/XP, Jeni Tennison |
Month |