<?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>3002</bug_id>
          
          <creation_ts>2006-03-15 11:56:09 +0000</creation_ts>
          <short_desc>[XSLT] xsl:next-match and pattern with |</short_desc>
          <delta_ts>2006-04-27 10:16:39 +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>Candidate Recommendation</version>
          <rep_platform>All</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>CLOSED</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="Joanne Tong">joannet</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>8730</commentid>
    <comment_count>0</comment_count>
    <who name="Joanne Tong">joannet</who>
    <bug_when>2006-03-15 11:56:09 +0000</bug_when>
    <thetext>Consider this example if the input is &lt;doc&gt;&lt;x/&gt;&lt;/doc&gt;:

&lt;xsl:template match=&quot;doc&quot;&gt;
  &lt;out&gt;
  	&lt;xsl:apply-templates select=&quot;x&quot;/&gt;
  &lt;/out&gt;
&lt;/xsl:template&gt;

&lt;xsl:template match=&quot;*:x|element(x)&quot;&gt;
	&lt;foo/&gt;
	&lt;xsl:next-match /&gt;
&lt;/xsl:template&gt;

&lt;xsl:template match=&quot;node()&quot;&gt;
	&lt;bar/&gt;
&lt;/xsl:template&gt;


Is the output:
	&lt;out&gt;&lt;foo/&gt;&lt;bar/&gt;&lt;/out&gt;
or
	&lt;out&gt;&lt;foo/&gt;&lt;foo/&gt;&lt;bar/&gt;&lt;/out&gt;

note that the priority for
	element(x) is 0
	*:NCNAME is -.25
	node() is -.5

It seems odd to me that xsl:next-match can match the template that it&apos;s declared in.  Is this the intention of the working group?

In section 6.4 Conflict Resolution for Template Rules:
&quot;If the pattern contains multiple alternatives separated by | , then the template rule is treated equivalently to a set of template rules, one for each alternative. However, it is not an error if a node matches more than one of the alternatives.&quot;

In section 6.7 Overriding Template Rules:
&quot;the xsl:next-match instruction considers all other template rules of lower import precedence and/or priority.&quot;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>8732</commentid>
    <comment_count>1</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2006-03-15 12:30:33 +0000</bug_when>
    <thetext>Good point. I think the output has to be &lt;out&gt;&lt;foo/&gt;&lt;foo/&gt;&lt;bar/&gt;&lt;/out&gt;: that is, we really do treat it as if the union template rule was &quot;rolled out&quot; into two separate rules, one for each branch of the union. The results might be odd, but anything else is likely to be odder. For example consider a case where the matching templates in order of decreasing priority are T1, T2, T1, T3: we have to say that if the first match is T1, then successive next-match calls will invoke T2, T1, and T3 in that order. Your case is the same but with T2 removed. I think this is currently well-specified even if the consequences might not have been predicted.

Michael Kay</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>8737</commentid>
    <comment_count>2</comment_count>
    <who name="Joanne Tong">joannet</who>
    <bug_when>2006-03-15 14:33:30 +0000</bug_when>
    <thetext>Thank-you for the clarification.  I prefer the output to be &lt;out&gt;&lt;foo/&gt;&lt;foo/&gt;&lt;bar/&gt;&lt;/out&gt;.  I suggest adding a warning in section 6.7 that xsl:next-match can match a template that it&apos;s declared in.

thanks,
Joanne</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>8863</commentid>
    <comment_count>3</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2006-03-24 23:34:09 +0000</bug_when>
    <thetext>The XSL WG considered this at the telcon this week and directed the editor to add a Note explaining the behavior. This note will be added after the bullet in 6.7 explaining the effect of xsl:next-match, and reads as follows:

&lt;note diff=&quot;add&quot; at=&quot;ZA&quot;&gt;As explained in &lt;specref ref=&quot;conflict&quot;/&gt;, a template rule whose match pattern contains multiple alternatives separated by  code&gt;|&lt;/code&gt; is treated equivalently to a set of template rules, one for each alternative. This means that where the same node matches more than one  alternative, and the alternatives have different priority, it is possible for  the &lt;elcode&gt;next-match&lt;/elcode&gt; instruction to cause the current template rule to be invoked recursively. This situation does not occur when the alternatives have the same priority.&lt;/note&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>9489</commentid>
    <comment_count>4</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2006-04-27 10:16:39 +0000</bug_when>
    <thetext>The change has been applied to the document so the bug is now closed.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>