Another Bug
Wednesday, 23 June 2010 · 5 messages
CG
Dave,
Quoted text · Dave Glick · 1 line
> ... (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 ;)
Quoted text · Dave Glick · 7 lines
> 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
Quoted text · Dave Glick · 38 lines
> 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >
CG
Quoted text · Dave Glick · 6 lines
> 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
CG
Christian Grün23 Jun 2010 17:51 #
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
Quoted text · Christian Grün · 26 lines
On Wed, Jun 23, 2010 at 5:16 PM, Christian Grün <christian.gruen at 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 >
DG
Dave Glick23 Jun 2010 18:03 #
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>DG
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...
Quoted text · Christian Grün · 2 lines
> 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
Quoted text · Christian Grün · 59 lines
-----Original Message----- From: Christian Grün [mailto:christian.gruen at gmail.com] Sent: Wednesday, June 23, 2010 10:37 AM To: Dave Glick Cc: basex-talk at 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >
Written for BaseX 6. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery