29690 2016-06-08 15:59:43 +0000 [XSLT30] Streamability rules, "must" process using streaming when construct is guaranteed streamable 2017-01-30 12:52:10 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC Windows NT RESOLVED FIXED P2 minor --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 126709 0 abel.braaksma 2016-06-08 15:59:43 +0000 Perhaps the most important rule on streamability is found in 19.10 and says that: 1) If a construct is guaranteed-streamable then it MUST be processed using streaming. This text, and the text around it, do not seem to say that when the supplied node is itself not a streamed node, then it will not be processed using streaming (consider the input to IMS, or a copy-of() call, or an apply-templates with a non-streamed input tree to a streamable mode). I propose something along the following: 1) If a construct is guaranteed-streamable and the input tree is provided as a streamed node, then it MUST be processed using streaming. I think this takes care of the scenarios where an input tree is not a streamed tree, or where a calling construct creates a non-streamed tree, or is itself invoked with a non-streamed tree. We could add a Note that says that it is an API matter how a processor provides a streamed node as input. Note also that we do not forbid a non-streamed node as input (except for xsl:stream and xsl:merge-source). 126710 1 abel.braaksma 2016-06-08 16:11:28 +0000 Another angle to this is: consider an initial-function invocation with a streamable function, the streamable argument can be of type "item()", but there is nothing to stream if you supply it a text node, or a string. In such cases, the current way 19.10, Rule (1) is written seems in conflict with itself.. 126744 2 mike 2016-06-13 16:45:23 +0000 The WG accepted the proposed change, however the editor was actioned to check whether there was any interaction with the resolution to bug #29472. 127264 3 abel.braaksma 2016-09-01 15:19:17 +0000 I'm wondering whether these changes have been applied to the most recent (last week's) internal WD. I didn't see a change log entry, and I think the original definition of this rule is still in place. 128426 4 mike 2017-01-30 12:52:10 +0000 On investigation I found that: (a) the necessary changes have been applied to the spec (b) for some reason the changes are tagged (quite wrongly) as belonging to the unrelated bug 29989 (c) there appears to be no entry in the change log. I have fixed this.