Saxon

Did you intend to add an attachment?

It seems there's an incorrect type inference for xsl:copy-of in this situation, it thinks it will return a node but in this case it will return a string.

In more detail, the situation is quite complicated. There are two phases of type-checking; the second phase is done with more context information and can refine the types inferred in the first phase. The first phase incorrectly infers a type of node() for the result of the copy-of instruction, and hence for the variable $ns-cleaned.

In the second phase, if the xsl:when condition is a simple one like (. instance of element()), then it is statically evaluated to false() because it is known by this stage that $atype is a string. Because it is statically false, no further checking of this branch of the conditional takes place, and the previous incorrect inference therefore has no adverse effects.

But the more complex condition (. instance of element() or . instance of document-node()) isn't being statically evaluated to false() (this is a missed optimization opportunity rather than a bug per se), and so further checking of the conditional branch takes place. This time "," is known to be a string, so the result of xsl:copy-of is known to be a string, but the required type of the variable is still thought to be node(), and the conflict is reported in the error message.

Three actions emerge:

(a) fix the type inferencing for xsl:copy-of

(b) precompute the result of "And" and "Or" expressions more aggressively if one or both arguments are statically known.

(c) the type inferencing for xsl:copy-of is unnecessarily complicated because a flag "isSchemaAware" is set to true; if this flag had been false, the type inferencing would simply assume that the result type is the same as the operand type. It seems this flag is always true, even in Saxon-HE. We should try to set it correctly. However, this is probably a risky change, so I won't do this on the 9.7 branch.