This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Test case square-array-040 uses the expression <xsl:copy-of select="[$extraItem, /BOOKLIST/BOOKS/ITEM]?*!PRICE"/> and expects this to be streamable. Until now, Saxon has been streaming it successfully. But I have now changed my code to match the spec more precisely, and I find that it fails streamability analysis. The reason is that ยง19.8.8 says that the operands of a square-array-constructor have operand usage navigation, and selecting streamed nodes in a navigation context automatically gives you a free-ranging expression. As far as I can see, the operand usage (for both square and curly array constructors) should be transmission.
I suspect the reasoning for using "navigation" here is basically that we don't define any machinery for streaming arrays member-by-member. The analysis therefore assumes that an array is assembled as a data structure in memory, and that means that it shouldn't contain any streamed nodes. A test like square-array-040 is untypical, because if the array is immediately reduced to a sequence by applying the "?*" operator, it can be streamed in the same way as a sequence containing the same nodes; effectively the expression [$extraItem, /BOOKLIST/BOOKS/ITEM]?*!PRICE can be rewritten as ($extraItem, /BOOKLIST/BOOKS/ITEM)!PRICE to make is streamable. I think we should deem the spec correct here, in which case this and similar tests are incorrect. Changing this to a test suite bug.
I have now modified the Saxon treatment so it essentially rewrites [A,B,C]?* as (A, B, C) which is essentially what was going on before, and that makes these tests streamable again - but I think they shouldn't be streamable according to the spec. There's one exception, test square-array-201 says in both the metadata and the comments within the stylesheet that it isn't streamable, but the expected result is successful execution. I think that's incorrect.
> but I think they shouldn't be streamable according to the spec. I know this is a rather old bug, but do you propose we fix the spec? I think it allows processor leeway in making more constructs streamable if it can. But the tests should probably be more rigid and be written according to the rules of the spec (that is: they should not be considered streamable).