This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Under 3.5.3.1 Visibility of Components we say: "The value may be a NamedFunctionRef only in the case of stylesheet functions, and distinguishes functions with the same name and different arity. " And under item (2): "If the package manifest contains an xsl:expose element that matches this component by virtue of an explicit EQName or NamedFunctionRef..." The process of "matches this component" is not specified further. I cannot find whether a token that is a NameTest, but not a NamedFunctionRef should match all functions by that name. I tend to think that a NameTest can match multiple functions, but once it can match multiple functions, may that raise conflicts with the rules, which seem to be written to match one component only, unless it's a wildcard match? Though if it doesn't match multiple functions, then expose/accept of functions becomes tedious. I think that the intent here is to expose/accept all functions by that particular name, similar as to how fn:function-available#1 works.
The intent here was that functions can be exposed/accepted only using a symbolic name of the form f:function#arity. The form f:function does not match anything. I think this should be clear from the phrase "The components in question are identified using their symbolic identifiers. " (follow the link to "symbolic identifier"). However for clarity, after "The value may be a NamedFunctionRef only in the case of stylesheet functions, and distinguishes functions with the same name and different arity." We could add "A NameTest on its own (that is, with no arity) cannot be used to identify a function."
On second thoughts and a more careful reading, I don't think there is evidence of what the original intent was, and I suspect there is simply an oversight here. Since we allow wildcards and partial wildcards selecting components by namespace or by local name alone, it would make sense to allow selecting all functions with a given name regardless of arity. However, this would feel to me like adding a new feature; if it had been intended, surely the spec would say so, or there would be a test case. So I retain my view that we should clarify the rules by saying: "A NameTest on its own (that is, with no arity) cannot be used to identify a function or a set of functions."
> However, this would feel to me like adding a new feature; if it had > been intended, surely the spec would say so, or there would be a test case. Actually, such test cases exist, accept-040, accept-041a/b/c, package-017, package-018 etc. These were written in 2014/2015, both by Michael Kay and myself. Also, see examples in bug#26781, bug#29233 and bug#29667, where all examples appear to use the syntax without '#' (granted, I wrote those examples). Of course, that is not spec-prose, but it does perhaps signify the expectation of spec-readers. Since we have both passed these tests, I would propose we change erratum E36. Perhaps we could simply say that a NameTest is implicitly expanded to NameFunctionRef of all functions in scope by that name. That way, we can treat such match as a specific name match and it would automatically conflict with a more specific name with #arity (meaning: names="f:myfunc" would always conflict with names="f:mayfunc#2"). For reference, the HTML version of E36, which was drafted 13 Feb 2019: https://htmlpreview.github.io/?https://github.com/w3c/qtspecs/blob/master/errata/xslt-30/html/xslt-30-errata.html#E36