On 02/26/2014 06:35 PM, Dirk Kirsten wrote:
Hello Jan
On 26/02/14 18:23, Jan Techter wrote:
Dear basex people,
I am new to this mailing list. So 'hello' first of all.
Hello to you, too :) Always happy to have new users.
In my understanding of xquery the following expressions should be equivalent
/self::match/string()
/string(self::match)
But running
xquery count((<match>foo</match>, <test>test</test>, <match>bar</match>)/self::match/string())
xquery count((<match>foo</match>, <test>test</test>, <match>bar</match>)/string(self::match))
I don't think these two expressions are the same and hence this does not seem to be a bug. According to the spec, string($arg) returns a zero length string, if $arg is an empty sequence. As self::match will return an empty sequence for the second element in the sequence (the <test /> element), this will result to a string and thus will be counted in the resulting expression.
Hope this helps.
Cheers, Dirk
Hi Dirk,
thank you for your immediate reply. I think this is not just about the specs of the string function but about how function calls inside a path expression should work. I couldn't find anything about that in the xquery specs. Maybe somebody could point me to the right section there.
My knowledge about xquery comes mainly from the book XQuery from Priscilla Walmsley who also wrote most of the functx functions. But functx:get-matches() doesn't work as expected in the basex implementation of xquery since she uses the second kind of expression above. In basex this produces a list with more entries than actual matches.
In the first case the expression self::match seems to evaluate to two nodes each of which is passed on to the string() function. Producing two strings in total.
Why should the expression self::match evaluate differently when directly passed to the string function as in the second case? And if it actually should evaluate to a sequence of three entries where the second entry is the empty sequence why should the string function evaluate this at all. Since it only takes single values.
So if the second expression evaluates at all it seems to me that the only sensible way is to make it equivalent to the first expression.
But maybe the specifications state something different which i am not aware of?
Best, Jan