XSLT correctness issues with //

http://www.llamalab.com/js/xpath/benchmark.html lists a number of JS tests.
 We're doing quite well on performance, but we disagree with FF's native
XPather on a number of tests

descendant::node()
  native returns 248 nodes
  ajaxslt returns 88 nodes
//LI[1]
  native returns 2 nodes
  ajaxslt returns 1 node
//LI[last()]/text()
  native returns 2 nodes
  ajaxslt returns 1 node
//LI[position() mod 2]/@class
  native returns 2 nodes
  ajaxslt returns 1 node

Not sure about that first one, but there's a pretty clear explanation for
all those "//LI" tests.  Haw-bin wrote:

----
I'm a little torn on this. It looks like one of the optimizations [Dan]
made back when we released AJAXSLT 0.8 is contrary to the XPath spec.
Specifically, in xpath.js LocationExpr.prototype._combineSteps , the
sequence of DESCENDANT_OR_SELF and CHILD is combined into DESCENDANT.
Unfortunately, the spec states explicitly that these are not equal:

NOTE: The location path //para[1] does not mean the same as the location
path /descendant::para[1]. The latter selects the first descendant para
element; the former selects all descendant para elements that are the first
para children of their parents.

This has us not passing muster on some of the llamalab benchmarks: 
http://www.llamalab.com/js/xpath/benchmark.html [www.llamalab.com]

What I'm torn about is ... that removing the combining code re-introduces a
pretty big performance hit, at least for the special browser we all know
and love. On the other hand, these inconsistencies mean that relatively
simple XPaths that work in other browsers with native engines potentially
won't work in IE.
----

It took me a while to get my head around this... basically, [1] modifies
the context within the slash, but since //LI[1] is really
/descendant-or-self::node()/LI[1], it only modifies the part after the
second slash.
Original issue reported on code.google.com by DanFabul...@gmail.com on 16 Jun 2008 at 7:12
dayvonjersen / ajaxslt

XSLT correctness issues with // #24
