Re: [xslt] "|" operator

[Ron Burk <ronburk hightechinfo com>]

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.