This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(probably editorial) This arose from a report against Exselt which was first considered an Exselt error but I think its behavior is correct. The way the error is currently described suggests that it is illegal to have an xsl:template declaration with no mode-attribute unless you declare the unnamed mode with an xsl:mode declaration. I don't think that is correct. The error currently (note the last sentence): <quote> It is a static error, when the effective value of the declared-modes attribute of an xsl:package element is yes, if the package contains an explicit reference to an undeclared mode, or if it implicitly uses the unnamed mode and the unnamed mode is undeclared. A mode is declared if the package contains an xsl:mode declaration for that mode, or if the mode is a public or final mode accepted from a used package. The offending reference may occur in the mode attribute of an xsl:template or xsl:apply-templates instruction, or in an [xsl:]default-mode attribute. The offending reference may be either an explicit mode name, or the token #unnamed treated as a reference to the unnamed mode. A package implicitly uses the unnamed mode if there is an xsl:template or xsl:apply-templates element with no mode attribute, and with no ancestor-or-self having an [xsl:]default-mode attribute. </quote> Consider: <xsl:package ...> <xsl:template name="foo">bla</xsl:template> </xsl:package> According to the definition above, this should raise an error (xsl:template has has no mode attribute). I propose the last sentence to be editorially update with something like: <proposal> A package implicitly uses the unnamed mode if there is an xsl:template with a match attribute but no mode attribute, or an xsl:apply-templates element with no mode attribute, and with no ancestor-or-self having an [xsl:]default-mode attribute. </proposal> This would make the above example legal. Only if rewritten like the following, would (correctly) throw XTSE3085 (it implicitly uses the undeclared default mode): <xsl:package ...> <xsl:template name="foo" match="/">bla</xsl:template> </xsl:package>
Note: I wonder what happens with apply-template invocation using the unnamed default mode. I assume this would trigger the XTDE0045. Alternatively we could stress that using function-call invocation or named-template invocation does NOT invalidate this error. I.e., it is thrown regardless whether the mode is actually used (though this follows from it being a static error).
(Abel points out that the problem is that the error definition appears to embrace named templates as well as template rules)
I have extricated the last sentence into a separate paragraph that follows the error definition, and it now reads: <p diff="chg" at="T-bug29699">For the purpose of the above rule, a package <emph>implicitly uses the unnamed mode</emph> if either of the following conditions is true:</p> <olist> <item><p>There is an <elcode>xsl:apply-templates</elcode> element with no <code>mode</code> attribute, and with no ancestor-or-self having an <code>[xsl:]default-mode</code> attribute.</p></item> <item><p>There is an <elcode>xsl:template</elcode> element with a <code>match</code> attribute and no <code>mode</code> attribute, and with no ancestor-or-self having an <code>[xsl:]default-mode</code> attribute.</p></item> </olist>
I think this is indeed an improvement. However, there's now a perceived discrepancy between the error in the addendum and the error in the text. Since the first sentence of the error actually covers the whole error, and the rest is merely explanation, I would like to suggest the editor to break it up more: [ERR XTSE3085] It is a static error, when the effective value of the declared-modes attribute of an xsl:package element is yes, if the package contains an explicit reference to an undeclared mode, or if it implicitly uses the unnamed mode and the unnamed mode is undeclared. <break-up-here /> The meaning of whether a mode is declared or not is covered elsewhere, same is true for using an explicit mode or the #unnamed explicit reference. Changing this (by breaking it up) has the added advantage of making this rather long error more readable. I won't reopen the bug, as I think whether or not this suggestion is followed up is a typical "at the editor's discretion" thingy ;).
Thanks, I have further broken up the error definition as suggested.