This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specification states: Every function name declared in a library module must (when expanded) be in the target namespace of the library module This seems an unnecessary constraint in the case of private functions: we should not impose restrictions that serve no useful purpose. Many users might find it more natural to use the "local:" namespace for private functions. Incidentally, I also checked to see what the uniqueness rules were for private functions. I noticed it says: It is a static error [err:XQST0034] if the expanded QName and arity (number of arguments) of the declared function are equal (as defined by the eq operator) to the expanded QName and arity of another function in *function signatures*. and the definition of "function signatures" is: "the set of functions that are available to be called from within an expression". Like other aspects of the static context, it is defining the static context in relation to an expression; but for the uniqueness rules, it's not obvious what this expression is. It might be better to say "equal () to the expanded QName and arity of another function declared or imported in the containing Prolog".
Is there an important reason to make such a change? I'm in favor of keeping things stable unless there's a good reason to change.
In yesterday's telcon, we decided to close this with no action. Changing a function from private to public should not require changing the name of the function. If the rules for naming private functions are different from the rules for naming public functions, then we may need to rename a function to make it public. Also, the benefits of allowing other namespaces seem minimal, and do not justify introducing changes to the specification at this point.
Spawned a new bug to cover function signature scope: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8873