Thanks Toon,
it's always interesting to hear about bugs that should have been encountered much earlier. This one might need some more time to be fixed, that's why I've added a sourceforge bug entry:
https://sourceforge.net/tracker/?func=detail&aid=2997544&group_id=19...
Your query can be broken down to the following one:
//a[b = //b]
The general problem is that we attach text() location steps to a path if we know that the correspondent node is a leaf node. This way, we can rewrite queries to use the index more easily. I.e., the upper query is rewritten to:
//a[b/text() = //b/text()]
As the b elements are leaves in your example, but never have text() children, the predicate yields false…
//a[ () = () ]
In fact, for the given document, your test (b = //b) will result in an empty string test "" = "". This might be why no one else has stumbled over this before.
The query info view in BaseX gives you some hint how queries are evaluated (…maybe you're using it anyway).
Thanks, Christian
PS: I've posted this to the mailing list to let others know as well.
On Thu, May 6, 2010 at 11:05 AM, Calders, T.G.K. t.calders@tue.nl wrote:
Dear Christian,
Sorry to bug you again. As you can guess, my lecture is on Thursday morning.
The following query still gives an incorrect output in basex 6.1.1:
for $b in //b, $a in //a where $a/b=$b return <binding> {$b} {$a}
</binding> ----- When applied on the following document: ----- <doc> <a id="1"> <b id="1"/> <c>1a</c> <c>1b</c> </a> <a id="2"> <b id="2"/> <c>2a</c> <c>2b</c> </a> </doc> ----- It returns an empty answer, whereas the correct answer creates 4 "binding"-elements (the where clause does not filter anything away as both "b"-elements in the document evaluate to "" under string()).
On the other hand,
let $x:=<doc> <a id="1"> <b id="1"/> <c>1a</c> <c>1b</c> </a> <a id="2"> <b id="2"/> <c>2a</c> <c>2b</c> </a>
</doc>
for $b in $x//b, $a in $x//a where $a/b=$b return <binding> {$b} {$a}
</binding> ----- Does produce the correct output. I noticed that this error is present in some earlier versions of basex as well (e.g., in version 5.7 which I used last year). The query was evaluated correctly, though, in versions 4.0 and 5.0.
Best regards, Toon
-----Original Message----- From: Christian Grün [mailto:christian.gruen@gmail.com] Sent: donderdag 29 april 2010 16:51 To: Calders, T.G.K. Cc: basex-talk@mailman.uni-konstanz.de Subject: Re: Strange query output
Dear Toon Calders,
thanks for your detailed bug report. Yes, this was a serious issue; the predicate was optimized for an accessing the index, although it was dependent on the query context. This is now fixed in the repository version 6.1.1 of BaseX:
http://basex.org/maven/org/basex/basex/6.1.1/
I've forwarded your mail to the mailing list to let others know about it as well.
All the best, Christian
On Thu, Apr 29, 2010 at 12:17 PM, Calders, T.G.K. t.calders@tue.nl wrote:
Dear BaseX developers,
First of all, many thanks for making this nice tool freely available. I use it in my Database class so the students can practice a bit with XPath and XQuery and they are all, without any exception, very enthusiastic about the tool.
During class today, however, one of the students encountered a strange query output; I reduced the example to its essence:
For the following document:
<errordoc> <instructor fname="Toon" sname="Calders"/> <lecturer fname="Toon" sname="Calders"/> </errordoc>
We ran the query "//instructor[@sname=../lecturer/@sname]" which returned an empty answer when executed with BaseX 6.1. (with previous versions it seems to work fine; e.g., 5.7).
On the other hand, the query:
let $x:=<errordoc> <instructor fname="Toon" sname="Calders"/> <lecturer fname="Toon" sname="Calders"/>
</errordoc>
return $x//instructor[@sname=../lecturer/@sname]
does return:
<instructor fname="Toon" sname="Calders"/>
Best regards, Toon Calders TU Eindhoven
___________________________
Christian Gruen Universitaet Konstanz Department of Computer & Information Science D-78457 Konstanz, Germany Tel: +49 (0)7531/88-4449, Fax: +49 (0)7531/88-3577 http://www.inf.uni-konstanz.de/~gruen