This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, the text under 1.2 Namespaces and prefixes, under the last bullet point, says the following about operators: <quote> These functions are not available directly to users, and there is no requirement that implementations should actually provide these functions. </quote> With the advent of higher order functions, it seems to make sense to allow these "virtual" operator functions to be made available to end users. This can, of course, be an implementation dependent feature. The text above does not necessarily discourage implementers to provide such functions, nor does it encourage it, but, other than other namespaces that are not specifically bound to functions (like the output namespace and the error namespace), the operator namespace is not defined. I would propose to make this namespace explicit. For implementers that (want to) provide such functions, i.e. for use with higher order functions or certain types of dynamic programming, it would be nice if the namespace used for the "op" prefix is the same for all of them. A candidate namespace that comes to mind is http://www.w3.org/2005/xpath-operators. Or alternatively, the standard function namespace. I think, if the WG considers such change, that the impact is minimal. It might suffice to just mention the namespace and a sentence like "implementers that do disclose these functions directly to end users, should use the namespace xxxx".
This has been requested and rejected before, though I'm afraid I can't immediately find the link. The main objection to doing it, I think, is that the functions were never designed for this purpose. If you consider using one of the boolean functions that does comparisons, for example, as an argument to fn:filter(), you quickly find that you need le, ge, gt, and ne variants of the function as well as equals() and less-than() variants; and for strings, the compare() function is useless because it doesn't return a boolean. If you look at the arithmetic functions, things like op:multiply have a precondition that the two arguments are the same primitive type, but they define no error condition when they aren't, because they expect the caller to have taken care of this (by applying numeric promotion rules to "equalize" the arguments). So the whole library would need to be re-designed to make it usable. A second objection is that a large number of tests would need to be written: we don't have the resources to do this. I do think it would be nice if there were a more concise way of expressing a function such as declare function($x, $y) {$x + $y} Rather than using a built-in name op:numeric-add#2 for this function, I think a much more useful enhancement would be to provide a concise syntax for inline functions, along the lines of Scala and other modern functional programming languages. For example λ{$1 + $2} where the presence of $1 and $2 both declare the argument and indicate how it will be used. The construct F{$1 + $2} is more concise than op:numeric-add#2, and it is also far more general. For example consider sort(//employee, λ{$1!@salary}) I chose λ, of course, so we could have a boke-shed argument about the concrete syntax. (It's a lambda, by the way, in case Bugzilla ever repeats its old trick of throwing away non-ascii characters).
I understand your objections, though my point was not necessarily to make it a normative part of the spec, it was more about the sentence: > and there is no requirement that implementations should > actually provide these functions about which I understood that it is not forbidden (MUST NOT) to do so. If it is not forbidden, it seems to make sense to at least provide a namespace for it. Even in the event that it is forbidden, it would still make sense to provide a namespace for it (as we do for "err" and "output"). The other half or your answer is far more interesting though. I remember that we discussed a possible syntax for lambda style functions briefly during a joined F2F in Prague, but it was dismissed at the time (probably as too late in the game). I like the suggestion of numbered arguments, alternatively we can think of the arrow notation (but, as you said, a notation discussion should probably be done after, and if, such proposal is considered). My idea of arrow notation: $a => {abs($a + 2)} (: one arg :) ($b, $c) => {$b lt $c} (: multi args :) () => {system-property('x')} (: no args :)
We should at least be clear whether exposing these operators is permitted or not. "No requirement" seems to imply that it is permitted, but I would rather have a clear statement.
There's nothing to stop you having a library of functions in a namespace of your own choosing whose local names are the same as, or vaguely similar to, the functions in the op: pseudo-namespace. You can have any library of functions in any namespace you like; it's not something we could possibly ban.
(In reply to Abel Braaksma from comment #0) > Currently, the text under 1.2 Namespaces and prefixes, under the last bullet > point, says the following about operators: > > <quote> > These functions are not available directly to users, and there is no > requirement that implementations should actually provide these functions. > </quote> I think we answer this question in the next sentence: <quote> These functions are not available directly to users, and there is no requirement that implementations should actually provide these functions. For this reason, no namespace is associated with the op prefix. </quote> These operators are not designed as a library for higher order functions. If we wanted to do that, more work is needed. Implementations can provide their own function libraries for this purpose.
Marking this as closed. I'm not sure why the status was resolved/fixed rather than resolved/worksforme, changing accordingly.