[Bug 25174] Buffering with xsl:try wrapped around xsl:stream or xsl:result-document

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