- From: <bugzilla@jessica.w3.org>
- Date: Fri, 16 May 2014 01:49:49 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25174 --- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> --- Following discussion during the telcon of April 10, 2014, the WG asked me to come up with a proposal. At that telcon, Michael Kay suggested to allow xsl:catch inside an xsl:stream instruction. I think that proposal has merit, because it uses existing syntax and has less side effect issues as the proposal in this bugreport (which adds an attribute on-error on xsl:stream) Here's an outline of the xsl:catch proposal: Allow the xsl:catch instruction to appear as a child of xsl:stream. It must be the last child element (similar to xsl:try), except for xsl:fallback. It will have an absent focus for both the sequence constructor and the the select attribute (reasoning: we try to catch an error on reading the input stream, so there will be no node to process). If this element is present, then, prior to processing the sequence constructor in xsl:stream, the processor must attempt to read and buffer the streamed input document up until the start of the root element (i.e., it must perform the same action that would be required for has-children(root()), as described in bug 25173). If it fails, the appropriate error is raised, which can then be caught by the xsl:catch element. If the error is not caught, it will bubble up and can be caught by a previous xsl:try/xsl:catch construct and the xsl:stream instruction is not evaluated further. If the error is caught, the sequence constructor of xsl:catch is processed and the rest of the sequence constructor of xsl:stream will be ignored. No rollback is necessary, because the body of xsl:stream has not yet been processed. If no error is raised, the xsl:catch instruction is ignored and processing continues as normal. Notes: Note 1: this is different from using fn:streaming-document-available, which will not throw an error but simply returns true or false, but has the potential side effect that upon a subsequent read in an xsl:stream instruction using the same URI, it may still raise an error. Note 2: this instruction cannot be used to catch errors raised by the body of the xsl:stream instruction, it will only catch errors resulting from the initial reading of the streamed input document, i.e. when it fails to construct a streamed document node. Note 3: this instruction is defined to allow graceful degradation without having to buffer the full result of streamed processing in case of a failure to read the input document. If you do want to catch errors during streamed processing, you can wrap the body of an xsl:stream element inside a regular xsl:try/catch, but this will incur the penalty that the processor will be required to buffer all output, which may be detrimental in certain streaming scenarios. Note 4: because xsl:catch has absent focus, its sweep and posture are motionless and grounded. Example: <xsl:stream href="http://example.org/{$docname}.xml"> <xsl:value-of select="count(//news)" /> <xsl:catch errors="err:FODC0005"> <xsl:text>Invalid docname specified.</xsl:text> </xsl:catch> </xsl:stream> As an aside: it came to my attention that we do not currently specify the error conditions for xsl:stream in regards to the input document. I assume they are the same as for fn:doc? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 16 May 2014 01:49:51 UTC