Saxon

I suspect the situation that's a little unusual here is that the compiled xsl:value-of expression, although it only accesses attribute nodes, includes an EmptyTextNodeRemover. Normally this would be eliminated by type analysis determining that no text nodes can be selected, but this has been thwarted by the conditional "else 'default'" which gives the expression a heterogenous type.

If we replace "else 'default'" with "else ()", the stylesheet runs correctly.

There seem to be two possible ways forward: we could get smarter about the type analysis, enabling the EmptyTextNodeRemover to be eliminated, or we could get smarter about the streamability analysis of an EmptyTextNodeRemover. (Or we could do both...)

More specifically, the xsl:value-of select block initially generates a MergeAdjacentTextNodes expression. Further analysis shows that only one of the subexpressions (the if expression) is capable of generating text nodes, therefore adjacent text nodes cannot occur, therefore the MergeAdjacentTextNodes expression can be replaced with the simpler EmptyTextNodeRemover expression.

Note that the code also works without failure if we change the conditional

 if (normalize-space(@att3)) then @att3 else 'default'

to

 if (normalize-space(@att3)) then data(@att3) else 'default'

I've added more careful type analysis to AdjacentTextNodeMerger. If any of the operands is a Block or a Choose (conditional expression) it now examines the operands to see if any of them can be a text node, and if they can't, then the filter for text nodes can be eliminated. This solves the problem for this test case, though it's probably not a universal solution.

In fact there's a simpler way of improving the type inference - in place of getItemType(), use getStaticUType(), which also has the advantage that it follows more closely the type inference rules in the XSLT streamability spec. Only snag is that we haven't implemented getStaticUType for the Atomiser class, but this is easily fixed.

This fix causes test case streamable-033 to fail.

This is caused by the fact that CopyOf does not implement the method getStaticUType().

Perhaps it would be safer if the default implementation of getStaticUType() did getItemType().getUType()? But the results might not conform 100% with the W3C streamability rules.