Saxon

I think that we're getting it wrong even for much simpler patterns of the form descendant::x except child::x. We're interpreting this to mean "match elements that match descendant::x and that don't match child::x" - which won't match anything. But the correct semantics are "match any x element E provided there is an ancestor A such that E is a descendant of A and is not a child of A". This will match any x element that has a grandparent.

So what about intersect?

Consider div[title='John']//para intersect div[title='Jane']//para .

The rule says that it matches a para $N that is present in the result of the expression

root($N)/descendant-or-self::node()/(child-or-top::div[title='John']//para intersect child-or-top::div[title='Jane']//para)

For a para to be present in the intersection, it must have a containing div with title="John" and a containing div with title="Jane", and these must be children of the same parent, which means in practice they must be the same div element, since the subtrees of two sibling elements don't intersect.

We're currently treating this pattern as matching any node that has an ancestor div with title="John" and an ancestor div with title="Jane", regardless of the relationship of these two ancestors.

So, are there special cases where we can treat X except Y as meaning "matches X and does not match Y"?

An obvious candidate is @* except @code. Similarly, I think * except title is safe. These are the cases that are likely to arise in practice, and it's important that they perform well. So I think I'll keep the rewrite for simple cases where both operands are axis expressions using the attribute or child axes. "intersect" is less likely to occur but we might as well apply the same rules. It should handle multiple operands, e.g. @* except (@code | @status) or @* except @code except @status.

But in fact we have another optimization for such expressions: we generate a NodeTest with a composite condition, for example child::(author|editor). So we'll have to see how these rewrites interact.

Can you please point to the spec on how intersect and except patterns should work?

I can see the grammar IntersectExceptExprP, but cannot find interpretation.

§5.5.3,

Specifically, an item N matches a pattern P if the following applies, where EE is the equivalent expression to P:

N is a node, and the result of evaluating the expression root(.)//(EE) with a singleton focus based on N is a sequence that includes the node N

Another case where we can use the current IntersectPattern and ExceptPattern logic is if one or both of the operands of except/intersect is independent of the context item: for example para except $specialParas. This includes patterns starting //, for example para except //appendix//para.

But not para except appendix//para, counter-intuitively.

More tests have been created in the xslt3 match test set, and further code changes have been applied to make sure they pass.