This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Based on my action item at the F2F to provide a scrub of the FO document regarding bug 1422 to look for other places where we may need to consider allowing empty sequence to provide static typing implementations the ability to call the functions without forcing users through major hoops, I came across two categories of functions: 1. Positional arguments being wrong. 2. Recently introduced functions that have inconsistent parameters. Note that the design has been that we do not allow empty for "steering" arguments that are most likely being given with a literal value. For all others, we should statically accept empty since the static type for the argument expressions will infer a type that allows empty in most cases. I will file separate dependent bugs for each function.
The working group considered this comment at its meeting today and decided not to accept it. A number of divergent reasons were given for not accepting these changes, including: For some of the specific cases, returning empty sequences instead of failing were regarded as unhelpful to users. Providing errors improves usability, it was felt, rather than undermining it. The consistency argument was not compelling, in that consistency with some functions would speak to one decision, and consistency with other functions would speak to the opposite decision. The spec has a whole range of functions and operators, some of which accept empty sequences and some of which don't, so full consistency is not achievable. For the "class B" functions, changing the semantics of well-settled and long- standing functions in the absense of a compelling argument to change is disruptive.