Saxon

I haven't been able to reproduce this. Can you give us more details about how you are running the code, including the platform you are running on?

Problem now reproduced - but not in my normal debugging environment!

The specification says that xsl:value-of, when the select expression returns an empty sequence, should deliver a zero-length text node, but the function is actually returning an empty sequence. Because the static type analysis inferred a type of text() for the function result, the code for the comparison is assuming that it won't get an empty sequence, and fails when it does. There is some interplay here with the precise way in which the transformation is run; the function has to be executed in push mode for the failure to occur.

I'm going to have to create a new IntelliJ project based on the Saxon10.3 HE code as issued in order to get to the bottom of this one.

The optimisations carried out at compile time appear to be correct. The body of the function is reduced to

ValueOf(lastOf(tokenize((), "/", "")))

which should be OK: when the operand of ValueOf is an empty sequence, the result of ValueOf should be a single zero-length text node, However, the push-mode evaluation of this instruction, which has changed in 10.x to stream the result to the serializer, actually delivers an empty sequence rather than a single zero-length text node.

I don't know why this path is only taken in these particular circumstances, but there's a flaw in the logic here, and it's not immediately obvious how to fix it.

This bug is proving surprisingly difficult. I've made various attempts at fixing it by detecting the case where the xsl:value-of/select selects an empty sequence and emitting a zero-length text node in this case; all my attempts cause regression to significant numbers of other tests.

The only fix I've found that causes no regression is to suppress the optimisation in ValueOf (specifically, pushing the output of the select expression directly to the serializer) in the case where the select expression is capable of returning an empty sequence.

So far there is only a single location in one of the stylesheets that is affected by it in our case and since it is trivial to avoid it (and in fact improve the stylesheet, there really is no reason to use value-of) we're sticking with upgrade. Thanks for the insights.

Indeed, basic good practice like (a) declaring the types of the parameters and return value of xsl:function, and (b) using xsl:sequence rather than xsl:value-of to return the function result, would have prevented the problem from occurring. But of course we have to treat it as a bug anyway.