This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I found myself wondering about this after realizing we were binding "foo" from the title to the Standard Error Namespace, which seems wrong. When I went over the spec, we mention this under xsl:catch: * That it is a list of tokens, each token a NameTest * That error names are QNames This suggests that "pref:*" must have "pref" statically bound to a namespace (we didn't). It also suggests that "foo" must be treated like other NameTests, for instance like match="foo". Section 9.7 defines what constructs the default element/type namespace can be used in (i.e., xpath-default-namespace). This section *does not* include, nor exclude xsl:catch/@errors. Assuming that no inclusion means exclusion, I think it should be either * no namespace * the static default namespace of the containing element However, either of those leads to a problem: * If it matches no namespace, this is not explicitly declared and can be considered an ambiguous read of the spec * if it matches the default namespace of the containing element, how to you match an error code in no namespace, without sometimes needing XML 1.1 redefinition of the default namespace? I would like to suggest to treat this similar to the @match attribute for templates, that is that it listens to the xpath-default-namespace setting. This seems reasonable, as in a way it is a (limited) pattern and brings this in line with similar constructs.
The names in the catch/@errors attribute are NameTests, and we define NameTest by reference to the XPath 3.0 specification, which states: An unprefixed QName, when used as a name test on an axis whose principal node kind is element, has the namespace URI of the default element/type namespace in the expression context; otherwise, it has no namespace URI. Clearly the "otherwise" case applies here. Furthermore, XSLT ยง5.1.1 ends with "In all other cases, a lexical QName with no prefix represents an expanded QName in no namespace (that is, an xs:QName value in which both the prefix and the namespace URI are absent)." and none of the other cases applies. Moreover, if any default were going to be useful it would be the error namespace, and if we had intended that we would certainly have said so. All these points apply equally to the error-code attribute of xsl:message and xsl:assert, which should certainly follow the same rules.
(In reply to Michael Kay from comment #1) > An unprefixed QName, when used as a name test on an axis whose principal > node kind is element, has the namespace URI of the default element/type > namespace in the expression context; otherwise, it has no namespace URI. > > Clearly the "otherwise" case applies here. Clearly, I missed that when reading through, and I thought I was thorough ;). I agree to your other points, it makes sense, thanks. I'll close this as "INVALID", as this isn't a bug and the spec is clear.