Strange query output

On Thu, Apr 29, 2010 at 12:17 PM, Calders, T.G.K. <t.calders at 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

On Thu, Apr 29, 2010 at 5:40 PM, Philip Oliver <phil3 at olivercomputing.com> wrote: > Christian - I was trying to update my Eclipse installation (Galileo SR2 on OS X) with the maven integration and it blew up my Eclipse installation. Not a BaseX problem but still annoying. I don't know much about Maven but I think I'd prefer to just build from the command line if possible using 'mvn' which is what I was doing with the 'mvn install'. Can you say what I should do in order to use 'mvn' at the command line (rather than Eclipse) to build BaseX to get a jar? > > Phil > > On Apr 29, 2010, at 11:37 AM, Christian Grün wrote: > >> Philip, >> >> thanks for the hint, it was work in progress. All JUnit tests should >> now run as expected. If not, just tell us (we note that many people >> have difficulties with the Eclipse/Maven integration, so I'm not sure >> if the current configuration meets all demands). >> >> Christian >> >> >> >> On Thu, Apr 29, 2010 at 5:00 PM, Philip Oliver >> <phil3 at olivercomputing.com> wrote: >>> Christian, >>> >>> In light of the bug report, I updated my SVN repository copy and did a 'mvn install', and got the following errors in the automated tests: >>> >>> ------------------------------------------------------- >>> T E S T S >>> ------------------------------------------------------- >>> Running org.basex.test.query.NamespaceTest >>> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.418 sec <<< FAILURE! >>> Running org.basex.test.query.FTTest >>> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec <<< FAILURE! >>> Running org.basex.test.cs.SemaphoreTest >>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.004 sec <<< FAILURE! >>> Running org.basex.test.cs.PermissionTest >>> BaseX 6.1.1 [Server] >>> >>> >>> >>> I don't know how significant these are, or if it's a result of me not properly building BaseX, but FYI. >>> >>> >> > >

On Thu, May 6, 2010 at 11:05 AM, Calders, T.G.K. <t.calders at 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 at gmail.com] > Sent: donderdag 29 april 2010 16:51 > To: Calders, T.G.K. > Cc: basex-talk at 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 at 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