30378 2018-12-17 22:06:47 +0000 [XSLT30] Streamability, error XTSE3195 does not disallow absence of for-each-source and for-each-item with the streamable attribute present 2018-12-20 19:23:50 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Recommendation PC Windows NT NEW P2 normal --- 1 abel.online mike public-qt-comments oldest_to_newest 129452 0 abel.online 2018-12-17 22:06:47 +0000 Error XTSE3195 reads as: "[ERR XTSE3195] If the for-each-item is present then the for-each-source, use-accumulators, and streamable attributes must both be absent. If the use-accumulators attribute is present then the for-each-source attribute must be present. If the for-each-source attribute is present then the for-each-item attribute must be absent. " But the prose doesn't cover the scenario where neither for-each-item and for-each-source are present, but streamable is present. I think the intent of this error is to prevent confusion with streamable="yes" and disallows its appearance in any other scenario unless for-each-source is also present. If we were to allow streamable="yes" with an absent for-each-stream, we'd run into conflict with the streamability rules for xsl:merge, which requires all expressions to be grounded and motionless. So the potential streaming input in that case would end up being non-streaming anyway. I suggest we fix it simply by adding the case to the error, for instance something like this: "[ERR XTSE3195] If the for-each-item is present then the for-each-source, use-accumulators, and streamable attributes must both be absent. If the use-accumulators *** and/or streamable *** attribute is present then the for-each-source attribute must be present. If the for-each-source attribute is present then the for-each-item attribute must be absent. " 129460 1 abel.online 2018-12-20 19:23:50 +0000 It appears that the resolution for bug #29804 wasn't applied completely, which deals with the scenario and permits the presence of use-accumulators, except that it is ignored unless streaming is requested. Not sure how to move forward with this, though what's written in comment#0 seems to be the least obtrusive way forward (but doesn't fully resolve the prev. bug), which is likely preferred considering we're in REC status.