This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We say in 3.2 [ERR XTSE0080] It is a static error to use a reserved namespace in the name of a named template, a mode, an attribute set, a key, a decimal-format, a variable or parameter, a stylesheet function, a named output definition, an accumulator, or a character map; except that the name xsl:initial-template is permitted as a template name. We might also care to qualify this for the name xsl:original; although this is not actually the name of any component, it is used in a context where a component name would normally appear.
Please note also that we do not say much about error codes in fn:error, xsl:assert and xsl:message, but we do say about standard namespaces that their use is very restrictive: "[…] and MUST be used only as specified in this and related specifications." And: "Reserved namespaces MUST NOT be used, however, in the names of stylesheet-defined objects such as variables and stylesheet functions.". We do not have a definition of what a stylesheet-defined object is, but I would assume error codes to belong in there. It is clear from this description that <xsl:variable name="err:somevalue" /> is disallowed, but is fn:error('err:somevalue') also disallowed? If it were disallowed, early discovery of non-existing errors is possible: for <xsl:catch errors="err:UNDEFINED" />, a processor can warn that the error will never be raised because it is not defined in the spec and homegrown errors with such name are impossible. Potentially, perhaps, this should even be an error case and the processor should statically raise an error that an unspecified error code in the standard error namespace is used. The accompanying error code as in the Description of this bug, does not mention this use as being forbidden, though perhaps it should be.
Following WG discussion: (a) I have added a note relating to the name "xsl:original", pointing out that it is used to refer to components but is not actually the name of any component. (b) I have moved section 3.2 to be closer to 5.1. Section 5 now has 5.1 Names 5.1.1 QNames 5.1.2 Unprefixed QNames 5.1.3 Reserved namespaces Section 5.1.1 no longer attempts to give an exhaustive list of named constructs; section 5.1.3 gives a complete list in the definition of the error code. (c) As actioned by the WG, I researched the question whether reserved namespaces should be permitted in the names of user-defined or implementation-defined error codes. I found that existing specfications were fairly clear that there were no constraints on the namespace used in such codes, and I concluded that introducing such a constraint was unnecessary, paternalistic, backwards-incompatible, and would require retrospective change to XPath 3.0.
For reference to Michael's action item, see: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Mar/0036.html (member only) (note: my answer to the mail can be disregarded, as mail 41 shows)