This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: For expressions and / operator in XPath 2.0 (Was: Re: result = node1 * node2 and then get total of all the result from whole document at the end)
- From: Jeni Tennison <jeni at jenitennison dot com>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Wed, 2 Jan 2002 23:15:50 +0000
- Subject: Re: For expressions and / operator in XPath 2.0 (Was: Re: [xsl] result = node1 * node2 and then get total of all the result from whole document at the end)
- Organization: Jeni Tennison Consulting Ltd
- References: <000901c193b6$030dede0$465169d5@pcukmka>
- Reply-to: xsl-list at lists dot mulberrytech dot com
Hi Mike,
> It would mean, for example, that sum(XXX/@value) would not
> necessarily give the same answer as sum(XXX/(@value+0)) (where XXX
> is an arbitrary expression); though it would give the same answer
> 99% of the time, which would make the exceptions even more
> surprising.
Gah, I see. There's sort of the same kind of thing with:
section[keyword = $keyword]
and
section[starts-with(keyword, $keyword)]
and
section/keyword[starts-with(., $keyword)]
which we have to answer questions about all the time.
> After months of agonising on this one, we just decided to keep
> things simple: "/" eliminates duplicates and returns results in
> canonical order, "for" retains duplicates and retains the ordering
> of the operand. I was sad to lose "sum(//rate/(@value * @quantity))"
> but I'd rather make it an error than have it return results that
> were difficult to explain to people.
It's a shame. I do dislike all the keywords that seem to have infected
XPath, which make it seem more like a programming language in its own
right than a simple expression language :( I don't suppose we could
get rid of this one and use some kind of symbol or operator instead,
like:
//rate -> (@value * @quantity)
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list