Saxon

The problem with this is that you can get match patterns like

chapter[count(.//word) > 50000]//para[starts-with(., 'The')]

where we have to try and make an intelligent decision on the best order of evaluation; there's nothing in the spec to say that the ancestor/parent conditions should be evaluated before the predicate conditions, and sometimes it can be much more efficient to evaluate the predicate first.

That leaves the question of whether to produce a warning if evaluation of the predicate fails, and I think it's best to do so because otherwise it's completely mystifying why the pattern didn't match. I'd suggest in your example rewriting it to avoid the failure, for example

match="foo/bar[exists(@key) and map:contains($myMap, @key)]

There's been a lot of discussion recently about order of evaluation of predicates or of terms in an "and" expression, for example if you write

match="bar[parent::foo and exists(@key) and map:contains($myMap, @key)]"

and in Saxon 12 we might still rearrange the order of terms, but we won't report an error if any one term fails and another term returns false. I guess that's essentially what you're asking for here...

My apologies, if there's nothing in the spec regarding emitting these warnings vs short circuiting them then I guess this is not a bug at all, it just seemed wrong at the moment I encountered it.

I realized the out of order evaluation was for optimization, but now I'm thinking that evaluating more of the expression just to know if a warning should be emitted could be a lot more checks...

You're certainly right that it's better to report warnings than not when something fails. And better to focus on the optimization than trying to stop an unnecessary warning from escaping, though there's the consideration that certain warning handling could be slower than another simple check (for me it can write to a log), but how could Saxon know...

I think the heart of this is that there's a difference in knowledge between me (the XSLT author) and Saxon here.

I know that the bars which are children of foo will always have a @key and can assume that map:contains($myMap, @key) is safe but Saxon can't know that without a schema (if one even exists) or by checking the "preceding" predicates to short circuit and avoid the warning.

I agree that your suggestion of match="foo/bar[exists(@key) and map:contains($myMap, @key)] is probably the right approach, I assume there's some implementation magic that makes exists(@key) evaluated first.

The discussion on how to weigh predicates and their terms to determine order of evaluation is certainly interesting though. I look forward to following any future developments.

Thanks!

Although there is no non-conformance here, the optimizer isn't doing a great job. It is computing the expected cost of the two expressions parent::foo and self::bar[map:contains($map, @key)] and has assigned them both the default cost of 1. Clearly the second expression is more expensive and the calculation needs to be refined.

(Note, ideally the calculation would not only estimate the cost of the expression, but also estimate its effectiveness as a filter. This is a case where the learning strategy that we're starting to use in 12.0 could play a role.)

No, that's a misdiagnosis. The optimizer's calculation is initially correct, but the pattern then gets copied as a result of a tree rearrangement, and in the course of this copying, the result of the calculation gets lost.

It's a one-line fix to retain the result through the copy operation (affects AncestorQualifiedPattern.copy())

Excellent! Thank you so much Michael.