> first of all, thanks for Jaxen and Saxpath. Good XPath implementations > are rare, and my benchmarks indicate that Jaxen is up to 10 times faster > than Xalan, so Jaxen qualifies as 'good' :)
Really? Rock! Would you care to share those benchmarks with the list? I'd love to see the numbers, but I personally have never touched Xalan, and don't intend to ever, so I won't be running any benchmarks anytime soon. > However, there seems to be a problem with your predicate evaluation. > Here's a sample XML document for recreating the problem. > > <?xml version='1.0'?> > <foo> > <bar> > <baz/> > <baz/> > <baz/> > </bar> > <bar> > <baz/> > <baz/> > <baz/> > </bar> > </foo> > > If you execute "/foo/bar/baz[1]" on this document, Jaxen returns a list > of size 1, presumably containing the very first "baz". The correct > behavior should be to return a list containing the first baz in the > first bar and the first baz in the second bar, i.e. a list of size 2. Right. > I suspect that Jaxen filters its nodes at the very end after retrieving > all nodes into a list, instead of filtering the nodes collected at every > step? It shouldn't. I certainly might be doing that, but I think we have the logic hooked up roughly correct. Would you like to try hunting down this exact bug? Hopefully this URL will work. If not, just look at DefaultLocationPath: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jaxen/jaxen/src/java/main/org/jaxen/expr/DefaultLocationPath.java?rev=1.8&content-type=text/vnd.viewcvs-markup The evaluate(...) method *looks* right to me, but certainly may have a sneaky little bug somewhere. But it shows that for each step, we evaluate the predicates. If you can't track down the bug, could you at least create a test-case for our test-harness, so we can replicate it in a controlled environment? -bob _______________________________________________ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
