Saxon

Handling motionless assertions is quite straightforward, with one caveat: it may be a bit tricky to ensure that the XPath expression does not attempt to access attributes of ancestor elements.

Handling consuming assertions is proving a bit more tricky, because of the complex structure of the validation pipeline.

The problem is basically that the ValidationStack sends the startElement() event down the pipeline (specifically, to the validator associated with its parent element), and this action determines the governing type for the child element. Only when we know the governing type do we know if there are any consuming assertions for the type, but by then it's too late to register a trigger with the WatchManager because the WatchManager has already processed the startElement() event.

I think the answer might be to have a second WatchManager that is only concerned with handling of assertions. The logic for this can go in the AssertionTreeBuilder class which is currently responsible for starting and stopping the building of temporary trees for non-streamed assertion evaluation.

Note that if a tree is already under construction for a part of the document in which a consuming assertion appears, then it's better to evaluate the assertion in non-streamed mode against that tree rather than to set up a streamed evaluation in parallel.