I think I've found another bug (I promise I don't spend my whole day sitting around thinking of ways to break Basex). The test XML is at the bottom of this message. I'm not sure how to classify this bug, but consider the results of the following queries with the initial context set to <bbb>.
Query: count(./preceding-sibling::*)+1 Result: 2 (as expected)
Query: /test/a/ab/*[2] Result: <abb> (as expected)
Query: /test/a/ab/*[count(./preceding-sibling::*)+1] Result: <aba><abb><abc> (was expecting just <abb> as before)
This problem also appears to affect FLOWR expressions when using "for" but not "let"...
Query: let $p := count(./preceding-sibling::*)+1 return /test/a/ab/*[$p] Result: <abb> (as expected)
Query: for $p in 2 return /test/a/ab/*[$p] Result: <abb> (as expected)
Query: for $p in count(./preceding-sibling::*)+1 return /test/a/ab/*[$p] Result: <aba><abb><abc> (was expecting just <abb> as before)
Text XML:
<test> <a> <aa/> <ab> <aba/> <abb/> <abc/> </ab> <ac/> </a> <b> <ba/> <bb> <bba/> <bbb/> <bbc/> </bb> <bc/> </b> </test>
Dave,
... (I promise I don't spend my whole day sitting around thinking of ways to break Basex) ...
Feel free to do so – we'll benefit ;)
The test XML is at the bottom of this message. I'm not sure how to classify this bug, but consider the results of the following queries with the initial context set to <bbb>.
[...]
Query: /test/a/ab/*[count(./preceding-sibling::*)+1] Result: <aba><abb><abc> (was expecting just <abb> as before)
This time, the answer is correct, as the context item expression (.) refers to the three context items, respectively, which result from the location path: <aba/>, <abb/>, and <abc/>.
Hope this helps, Christian
This problem also appears to affect FLOWR expressions when using "for" but not "let"...
Query: let $p := count(./preceding-sibling::*)+1 return /test/a/ab/*[$p] Result: <abb> (as expected)
Query: for $p in 2 return /test/a/ab/*[$p] Result: <abb> (as expected)
Query: for $p in count(./preceding-sibling::*)+1 return /test/a/ab/*[$p] Result: <aba><abb><abc> (was expecting just <abb> as before)
Text XML:
<test> <a> <aa/> <ab> <aba/> <abb/> <abc/> </ab> <ac/> </a> <b> <ba/> <bb> <bba/> <bbb/> <bbc/> </bb> <bc/> </b> </test> _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Of course, duh! And that explains why the let expression worked - because the value of $p was evaluated using the root context before the axis steps started to be taken. But what about the case with the for expression...
Query: for $p in count(./preceding-sibling::*)+1 return /test/a/ab/*[$p] Result: <aba><abb><abc> (was expecting just <abb> as before)
Is the value of $p not evaluated until it's used from within the return?
Thanks again,
Dave
-----Original Message----- From: Christian Grün [mailto:christian.gruen@gmail.com] Sent: Wednesday, June 23, 2010 10:37 AM To: Dave Glick Cc: basex-talk@mailman.uni-konstanz.de Subject: Re: [basex-talk] Another Bug
Dave,
... (I promise I don't spend my whole day sitting around thinking of ways to break Basex) ...
Feel free to do so - we'll benefit ;)
The test XML is at the bottom of this message. I'm not sure how to classify this bug, but consider the results of the following queries with the initial context set to <bbb>.
[...]
Query: /test/a/ab/*[count(./preceding-sibling::*)+1] Result: <aba><abb><abc> (was expecting just <abb> as before)
This time, the answer is correct, as the context item expression (.) refers to the three context items, respectively, which result from the location path: <aba/>, <abb/>, and <abc/>.
Hope this helps, Christian
This problem also appears to affect FLOWR expressions when using "for" but not "let"...
Query: let $p := count(./preceding-sibling::*)+1 return /test/a/ab/*[$p] Result: <abb> (as expected)
Query: for $p in 2 return /test/a/ab/*[$p] Result: <abb> (as expected)
Query: for $p in count(./preceding-sibling::*)+1 return /test/a/ab/*[$p] Result: <aba><abb><abc> (was expecting just <abb> as before)
Text XML:
<test> <a> <aa/> <ab> <aba/> <abb/> <abc/> </ab> <ac/> </a> <b> <ba/> <bb> <bba/> <bbb/> <bbc/> </bb> <bc/> </b> </test> _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
But what about the case with the for expression...
Query: for $p in count(./preceding-sibling::*)+1 return /test/a/ab/*[$p] Result: <aba><abb><abc> (was expecting just <abb> as before)
Is the value of $p not evaluated until it's used from within the return?
True; by dumping the query info I found that the 'for' expression is optimized as follows…
/test/a/ab/*[count(preceding-sibling::*) + 1]
…which is unexpected if you have predefined a context item, such as in your case (by default, you'll get the appropriate error mesage that the context item has not been specified). This one might take a little bit longer, as we've hardly had the time to look at predefined context items yet (most of our users seem to start their queries from the root node, or from nodes specified in the query itself – if someone else feels addressed here, please tell us); you'll be notified, however, as soon as a handsome solution on this has been found.
Thanks, Christian
Good news Dave, I found an obvious solution for your observation (I've readded a context item check that had been removed some time ago due to some mystic reason). Please check out the latest sources.
Christian
On Wed, Jun 23, 2010 at 5:16 PM, Christian Grün christian.gruen@gmail.com wrote:
But what about the case with the for expression...
Query: for $p in count(./preceding-sibling::*)+1 return /test/a/ab/*[$p] Result: <aba><abb><abc> (was expecting just <abb> as before)
Is the value of $p not evaluated until it's used from within the return?
True; by dumping the query info I found that the 'for' expression is optimized as follows…
/test/a/ab/*[count(preceding-sibling::*) + 1]
…which is unexpected if you have predefined a context item, such as in your case (by default, you'll get the appropriate error mesage that the context item has not been specified). This one might take a little bit longer, as we've hardly had the time to look at predefined context items yet (most of our users seem to start their queries from the root node, or from nodes specified in the query itself – if someone else feels addressed here, please tell us); you'll be notified, however, as soon as a handsome solution on this has been found.
Thanks, Christian
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Dave Glick