[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] priority of key patterns

---

---

On 14/11/2012 06:51, Ihe Onwuka wrote:

Would I be right in concluding that the default priority of the first
template below that features a call to a key function in the match
pattern is 0.5.

Yes (the spec is fairly clear, I think).

   <xsl:template match="key('privateData','private')" priority="-0.1">
     <private oldName="{local-name()}">
       <xsl:apply-templates select="node()|@*"/>
     </private>
   </xsl:template>

   <xsl:template match="*|PayloadFile">
    <xsl:element name="{local-name()}">
       <xsl:apply-templates select="node()|@*"/>
    </xsl:element>

Your second template rule is rather peculiar, because the first alternative (*) embraces the second (Payloadfile); except that they have different priorities, so this is almost equivalent to writing a match="*" template with priority -0.5, and a match=Payloadfile template with priority 0. Unless there's another template rule with intervening priority, the second half of the union is pointless.

(I say "almost equivalent", because it's not quite the same as two separate rules: the effect of xsl:next-match is different).

I found myself having to override the priority in order to ensure that
the PayloadFile element (otherwise caught by the key) would be
processed by the 2nd template rule.

Fine. So? That's what priorities are for.

Incidentally, I very rarely see key() used in patterns. I'd be interested to know the use case. In XSLT 3.0 we're allowing a variable reference as a pattern, so you can do for example

<xsl:variable name="oddities" select="//w:X[preceding-sibling::*[1][self::w:Y[w:Z]]]">

<xsl:template match="$oddities">...</xsl:template>

and I've seen key() patterns used for this kind of use case in 1.0 and 2.0 - the actual key is generally immaterial.

On an unrelated note not worth starting a new thread, I tried using
except in an xsl:key match clause - which was rejected. I presume it
is one of those pattern rules that I keep falling foul of (XSLT 2.0).

Yes. Patterns become less restrictive in XSLT 3.0. Unfortunately this makes the default priority rules even more complicated.

Michael Kay
Saxonica

---