Saxon

Looking at one of the failing tests, exists-004, and it appears that it is doing an early exit, but failing to report the fact.

If we compare with exists-001,

• in exists-001, ExistsStreamer.action() calls getTerminator().terminate(); this throws the QuitParsingException, which is caught by in WatchManager.startElement(), resulting in a call to warning().

• in exists-004, ExistsStreamer.action() calls getTerminator().terminate(); this throws the QuitParsingException, which is caught and rethrown a couple of times by ItemFeed.processItems(), and is then caught be WatchManager.endElement(). This issues the requisite number of endElement() calls before rethrowing the exception; there is code in WatchManager.endElement() to issue the warning, but it is commented out. (This is also true in 9.9)

Reinstating the code to issue the warning makes the test pass (the early exit is now detected by the test driver).

(Perhaps the warning was removed because it was considered inappropriate to issue warnings when everything is running correctly and to plan? This should really be an "info" message rather than a warning. Perhaps the new ErrorReporter interface gives us an opportunity to add another severity level to the condition being reported?)

We're now getting test "failures" on a number of tests such as sf-exists-104 to -109 because they're doing an early exit when the test doesn't suggest it. This clearly shouldn't be a test failure, though it's an opportunity for improving the test. I've changed the test in these cases to expect early exit. That's still leaving failures in -100 .. -104 where early exit is expected by isn't reported as happening.

Looking at exists-100, the QuitParsingException is being thrown as before, but this time during execution of WatchManager.deferredStartDocument() called from WatchManager.startElement(), and on this path the QuitParsingException isn't being caught and notified. Fixed this by moving the call on WatchManager.deferredStartDocument() within the scope of the try/catch.

This leaves exists-101. This time the QuitParsingException is thrown during the call on endDocument. It's not clear that we should really count that as being 'early exit'. What's happening in this test is that the argument to exists contains first, nodes from the streamed document, and then, a sequence of atomic values; and it's the sequence of atomic values that isn't being read to completion. It's a bit arbitrary what we report in this case so long as the test actually succeeds, so I shall simply change the test to remove the "early exit" label.

Looking at other test sets, some of the "early-exit-possible" tags seem questionable. For example sx-intersect-021 does

select="(/BOOKLIST/BOOKS/ITEM[1]//text() intersect  $insertion

Saxon works out statically that the intersection is empty by type analysis; this means the streamed document is never read, so there is no early exit. So we can't afford to be too strict in evaluating these results.