- From: <bugzilla@jessica.w3.org>
- Date: Wed, 08 Jun 2016 15:59:43 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29690 Bug ID: 29690 Summary: [XSLT30] Streamability rules, "must" process using streaming when construct is guaranteed streamable Product: XPath / XQuery / XSLT Version: Candidate Recommendation Hardware: PC OS: Windows NT Status: NEW Severity: minor Priority: P2 Component: XSLT 3.0 Assignee: mike@saxonica.com Reporter: abel.braaksma@xs4all.nl QA Contact: public-qt-comments@w3.org Target Milestone: --- 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). -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 8 June 2016 16:00:02 UTC