Saxon

stylesheet file attached

It's a good idea to start here with the spec. XSLT section 2.14 explains it like this:

[Definition: Certain errors are classified as type errors. A type error occurs when the value supplied as input to an operation is of the wrong type for that operation, for example when an integer is supplied to an operation that expects a node.] If a type error occurs in an instruction that is actually evaluated, then it must be signaled in the same way as a dynamic error. Alternatively, an implementation may signal a type error during the analysis phase in the same way as a static error, even if it occurs in part of the stylesheet that is never evaluated, provided it can establish that execution of a particular construct would never succeed.

I often refer to this as "optimistic static typing" - (a) do as much type checking statically as you can, (b) if you find a construct that is bound to fail if executed, report it immediately, (c) if you find a construct that might or might not succeed, generate code to do the type checking at run-time. As the spec says, this may result in type errors being reported in code that is never executed (just as it would be in a strongly typed language). The principle, of course, is that it's much better to know about errors in your code from the compiler than to only discover them when you run tests with suitable test data, or worse still, in production.

The static type checking that is done isn't defined by the spec, processors are allowed to be as smart as they like in the inferencing. There are some cases where Saxon let's you get away with something that's technically a type error, for example when an xsl:choose has no xsl:otherwise clause, on the basis that it's quite common to write an xsl:choose in which the xsl:when clauses cover all the possibilities. But it can sometimes happen that the error is in a path that genuinely and by design will never be executed, in which case the static type error can be a bit irritating.

Let's look at how these principles apply in your case.

In the first example, Saxon has made a static type inference that the type of $test2 is xs:boolean, and from that it has worked out that the type of $value is xs:boolean, so it has worked out statically that you're supplying a boolean to the function my:handle-map which expects a map, That function call can never succeed, so it's legitimate to report a static type error even if the function call is never executed. It would also be legitimate, incidentally, to execute the function call at compile time, since its result has no dependencies on any run-time information. For example, if you wrote abs(-2) then Saxon would reduce that to the number 2 during compilation (a process that compiler-writers call "constant folding").

In the second example, Saxon could have legitimately raised a type error here, but it has chosen not to. Instead it has noticed that the expression $value instance of map(xs:string, item()) can be evaluated statically to false, and since the if condition is false, the then branch can be discarded and analysed no further.

Going back to the first example, Saxon could have done the same thing: that is, evaluated my:is-my-map() to false statically. In fact, I think that if it hadn't found the type error first, it would probably have done so. So there's an element of unpredictability here: the effect depends on the order in which different expressions are type-checked and optimized.

The bottom line is that "optimistic static type checking" is something that is permitted but not required by the spec. Saxon tries to do it as extensively as possible, both to give early diagnostics for problems and to eliminate the cost of unnecessary run-time type checking. But there's no non-conformance if it isn't done under any particular circumstances.