Saxon » SaxonJS

Looking at match-266, the compiled pattern in the SEF file is clearly incorrect:

{
                           "N": "p.withUpper",
                           "role": "match",
                           "axis": "parent",
                           "sType": "1NE u[NE nQ{}a,NE nQ{}b]",
                           "ns": "= xml=~ fn=~ xsl=~ xs=~ ",
                           "C": [
                              {
                                 "N": "p.venn",
                                 "op": "union",
                                 "C": [
                                    {
                                       "N": "p.nodeTest",
                                       "test": "NE nQ{}a"
                                    },
                                    {
                                       "N": "p.nodeTest",
                                       "test": "NE nQ{}b"
                                    }
                                 ]
                              },
                              {
                                 "N": "p.nodeTest",
                                 "test": "NE nQ{}x"
                              }
                           ]
                        },

because it applies the parent axis (rather than ancestor) to both branches of the union.

SaxonJ handles this (at SlashExpression#843) by rewriting a/(b|c) as (a/b union a/c).

I think the problem is in the Javascript XPath parser code, specifically Step.js line 83, SlashExpression.toPattern(), where the creation of an AncestorQualifiedPattern assumes that the RHS is an AxisExpression. Either there should be special logic here to handle the case where the RHS is a VennExpression, or it should construct a general-purpose GenNodePattern.

I've changed SlashExpression.toPattern() to generate a p.genNode pattern where the RHS is not an AxisExpression. The SEF file looks correct; but the pattern is not matching.

The reason for this is that the x element in the source being matched is parentless. We aren't doing the rewrite of child::x to top::x required by the spec, so the pattern x/a is treated strictly as child::x/child::a; the x doesn't match because it isn't the child of anything.

(Aside: I don't see anything in SaxonJ GeneralNodePattern to handle this either.)

Work on this bug has triggered the construction of a number of new test cases (some of which were also failing in SaxonJ).

At the moment we are failing match-254, match-265, -6, -7, -8, 273, -4, -5, 6,