<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://www.w3.org/Bugs/Public/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4"
          urlbase="https://www.w3.org/Bugs/Public/"
          
          maintainer="sysbot+bugzilla@w3.org"
>

    <bug>
          <bug_id>5278</bug_id>
          
          <creation_ts>2007-11-22 08:39:53 +0000</creation_ts>
          <short_desc>[XSLT 2.0] Can xsl:message cause an error?</short_desc>
          <delta_ts>2008-07-10 15:13:53 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>XPath / XQuery / XSLT</product>
          <component>XSLT 2.0</component>
          <version>Recommendation</version>
          <rep_platform>PC</rep_platform>
          <op_sys>Windows XP</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Michael Kay">mike</reporter>
          <assigned_to name="Michael Kay">mike</assigned_to>
          
          
          <qa_contact name="Mailing list for public feedback on specs from XSL and XML Query WGs">public-qt-comments</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>17829</commentid>
    <comment_count>0</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2007-11-22 08:39:53 +0000</bug_when>
    <thetext>xsl:message is generally used for diagnostics, and it would seem therefore undesirable that the instruction should ever cause a dynamic error (assuming terminate=&quot;no&quot;).

In particular, the specification says &quot;The xsl:message  instruction causes the creation of a new document, which is typically serialized and output to an implementation-defined destination.&quot; It doesn&apos;t say what happens if the creation of the new document or the serialization of that document fail.

Specifically, what happens if the user does:

&lt;xsl:message select=&quot;@*&quot;/&gt;

Saxon 9.0, unlike previous releases, is failing with error XTDE0420 which occurs when you try to create (or serialize) a document node that has attribute nodes as its children.

We currently say nothing. We could say that xsl:message MUST NOT or SHOULD NOT fail with a dynamic error, and use words that encourage the implementation to use an implementation-dependent fallback representation is such situations.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>18652</commentid>
    <comment_count>1</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2008-01-31 17:49:08 +0000</bug_when>
    <thetext>Discussed on 31 Jan 2008. There was a range of views, converging on a consensus that we should at least say that implementations &quot;may&quot; treat this as a recoverable error, and leaning towards a &quot;should&quot;. Editor asked to produce wording reflecting this.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>18824</commentid>
    <comment_count>2</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2008-02-07 16:44:24 +0000</bug_when>
    <thetext>I propose that we handle this in the same way as errors in patterns (see 5.5.4). Specifically, I suggest that we add to the end of section 17:

Any dynamic error that occurs while evaluating the select expression or the contained sequence constructor, and any serialization error that occurs while processing the result, is treated as a recoverable error even if the error would not be recoverable under other circumstances. The optional recovery action is implementation-dependent.

Note: An example of such an error is the serialization error that occurs when processing the instruction &lt;xsl:message select=&quot;@code&quot;/&gt; (on the grounds that free-standing attributes cannot be serialized). Making such errors recoverable means that it is implementation-defined whether or not they are signaled to the user and whether they cause termination of the transformation. If the processor chooses to recover from the error, the content of any resulting message is implementation-dependent.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>19556</commentid>
    <comment_count>3</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2008-03-20 11:27:30 +0000</bug_when>
    <thetext>The WG agreed to accept the text proposed in comment #2, with the addition of a suggestion that one possible recovery action is to include a description of the error in the generated message text.

Erratum E20 has been drafted.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>