Saxon

For the particular pattern in this example, fixing this should be fairly easy - extend PatternMaker.getAxisForPathStep() to recognise a union expression in which all subexpressions use the same axis.

A more challenging case is x/(child::a | descendant::b) which also appears to be a legal pattern. To handle the general case we may be best off expanding this to x/child::a | x/descendant::b.

Note in passing: this doesn't actually affect the outcome, but it appears that Saxon fails to remove the document-order sort operation from the path expression x/(a|b), i.e it fails to detect that the expression is "naturally sorted".

Actually I think the sort will be removed from x/(a|b) during the optimization phase, by virtue of the fact that (child::a|child::b) is effectively rewritten as child::*[self::a or self::b]. But for various (probably sound) reasons, the conversion of an expression to a pattern occurs before the optimisation phase is run.

Where this comes up in our use case, we are producing the paths (match patterns) programmatically, and they take the form of (a | b/c) / (d | e/f) / (x | y/z) of arbitrary length (though rarely more than two). We could perhaps find a way to produce better paths (and maybe should do so in any case).

Many thanks! Wendell

Added some more permutations of paths and unions in tests match-266 to -268.

I have fixed the case where the branches of the union use the same axis (tests match-265, -269) by adding another condition to PatternMaker.getAxisForPathStep.

For the asymmetric case such as a/(child::b | descendant::c) it seems best to distribute the ancestry condition, turning it into a/child::b | a/descendant::b.

I have adopted this approach and these tests now pass.