RE: What is the call-site of errors in sequences?

That implies that the following will return "eager-throw":

 

<xsl:try>

    <xsl:for-each select="1,2,error(xs:QName('err:test3')),4,error(xs:QName('err:test5'))">

       <xsl:try>

          <xsl:value-of select="." />

          <xsl:catch>

             <xsl:value-of select=" 'lazy-throw' " />

          </xsl:catch>

       </xsl:try>

    </xsl:for-each>

    <xsl:catch>

       <xsl:sequence select="'eager-throw'" />

    </xsl:catch>

</xsl:try>

 

I am not sure this is either intuitive or useful (if compared with the $errors variable approach). I mean, it seems to make sense being able to pass around a sequence that includes errors, without raising the error unless you force its evaluation (that is, unless you are in final result state). I.e., the following may or may not throw (given the current rules on XPath), which seems to be somewhat illogical w.r.t. how we do this in XSLT:

 

(1,2,error(xs:QName('err:test3')),4,error(xs:QName('err:test5')))[1]

 

Or even:

(1,2,error(xs:QName('err:test3')),4,error(xs:QName('err:test5')))[4]

 

 

Which implies that, if we take the original example but make sure that the XPath itself skips the errors, we may get an error-free sequence (implementation-dependent, eager evaluation is always allowed):

 

let $errors := (1,2,error(xs:QName('err:test3')),4,error(xs:QName('err:test5')))

return $errors[position() = (1,2,4)]

 

Again, it feels a bit as if the XPath rules are (somewhat) in conflict with the XSLT rules, though I am not certain if, or how this could/should be fixed.

 

The way I see it is in a functional way: we have a sequence of items, of which some items are of type xs:error. To prevent side-effects (which the current rules seem to imply), such a sequence should exist and be allowed to be passed around. That would imply f(x) => x for each x E xs:error and try(f(x),catch(y)) => if(f(x) = y) then catch(y) else f(x)), where y E xs:error and f, try and catch are functions.

 

In XSLT terms, I mean these expressions to be like the following:

 

<xsl:function name="f:catch">

   <xsl:param name="seq">

   <xsl:sequence select="$seq"/>

</xsl:function>

 

<xsl:function name="f:try">

   <xsl:param name="seq">

   <xsl:param name="catch ">

   <xsl:try>

      <xsl:sequence select="$seq"/>

      <xsl:catch><xsl:sequence select="f:catch($catch)" /></xsl:catch>

   </xsl:try>

</xsl:function>

 

let $errors := (1,2,error(xs:QName('err:test3')),4,error(xs:QName('err:test5')))

return $errors!f:try(., 'error')

 

Which, given your explanation wouldn't work. But if $seq and $catch were XPath expressions (that is, not a variable), they could work.

 

Cheers,

Abel

 

 

From: Michael Kay [mailto:mike@saxonica.com] 
Sent: Thursday, September 22, 2016 3:44 PM
To: Abel Braaksma
Cc: Public XSLWG
Subject: Re: What is the call-site of errors in sequences?

 

The error() calls happen outside the scope of either xsl:try, and they are not caught. Rule 1 bullet 3:

 

1. All dynamic errors occurring during the evaluation of the  <http://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html#element-try> xsl:try sequence constructor or select expression are caught (provided they match one of the  <http://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html#element-catch> xsl:catch elements).

* [This] does not include errors that occur while evaluating references to variables whose declaration and initialization is outside the  <http://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html#element-try> xsl:try.

We've experimented with various ways of achieving this. At present we're forcing eager evaluation of local variables that are declared outside an xsl:try and referenced within it.

 

Michael Kay

Saxonica