[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 #3 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
Re comment 2:

I thought of it, but I think we run into even more trouble, consider:

<xsl:try>
   <xsl:stream href="good.uri">
      <xsl:apply-templates select="x" />
   </xsl:stream>
   <xsl:catch ="err:Special">
      <xsl:message select="'Rolled back'" />
   </xsl:catch>
</xsl:try>

<xsl:template match="x">
   <xsl:try>
      <xsl:value-of select="@y mod @z" />
      <xsl:stream href="{@baduri}">
         <xsl:apply-templates />
      </xsl:stream>
      <xsl:catch select="*">
         <xsl:message select="'What is rolled back?'" />
      </xsl:catch>
   </xsl:try>
</xsl:template>

The second try/catch must somehow differentiate between
1) buffering and rollback current context in case of div by zero
2) poking @baduri for I/O and rolling back without applying templates
3) buffering apply templates and rolling back
4) if halfway streaming getting I/O error, rolling back apply templates

Even though implementations might be able to do this, I don't think it is good
to have one construct follow different semantics by one the same syntax and
different rollback behavior with potentially the same (I/O) error.

Which is why I presently prefer the (slightly) different syntax (xsl:catch as
child of xsl:stream) where the position and focus of xsl:catch makes it
unambiguous what is going on and what is going to be caught and/or rolled back.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 22 May 2014 11:12:41 UTC