To elaborate further. As an optimization, the code tries to treat ".|one" as a pattern rather than sending it to the normal, full xpath expression code. In every place that a pattern is legal, the expression ".|one" would be indistinguishable from "." (I think, if not then that means an additional bug). So, the code to evaluate a "stream" compiled by the pattern code will exit early when the first term in an '|'-ed together pattern expression is '.'.
The presence of any parenthesis (or some other special characters) will prevent that optimization branch from being taken, which is why the bug initially appeared like a failure to treat parentheses correctly. However, the code that hopes to optimize by invoking the pattern code instead of the normal, full xpath expression code, seems to believe that the pattern code will calculate a full result set. So, if you look at the result set after you ask the pattern code to check for ".", you get one node. After asking it to check for ".|one", you get one node. After asking it to check for ".|one|two", you get one node. After asking it to check for ".|one|two|three", you get one node. OTOH, if you look at the result set after you ask the pattern code to check for "one|.|two|three", you get two nodes. Whenever it runs into that ".", it's done. It's an optimization that probably works fine for the pattern code, but not for any caller who wanted the result set, not just a true or false answer. That is the internal explanation of the bug, I believe, but there are too many optimizations and other complexities for a newcomer to the code to propose any robust fix, apart from the obvious brute-force disabling of XPATH_STREAMING. _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
