RE: [F&O] 15.3 Aggregate Functions

> Allowing the functions fn:max, fn:min and fn:avg to accept an 
> empty sequence as argument is wrong and will make using these 
> functions difficult and confusing.
> 
> Trying to calculate the minimum, maximum or average of an 
> empty sequence is an error and must be reported at the place 
> where this error occurs.
> 
> Returning the empty sequence instead is delaying the moment 
> at which it is realized that there is an error. 

You are making assertions here which are not self-evident. There are
different design options here, which have different pros and cons, and the
optimum solution isn't obvious at all.

One of the arguments is that when static typing is in force, a type
signature of xs:double+ would not only require the dynamic type to be
one-or-more numbers, it would also require the static type to be
one-or-more. So users of static typing systems (for whom, I must say, I have
little sympathy) would have to write min(one-or-more(book/@price)).

Another argument is that allowing the ()->() behavior is consistent with
many other functions and operators in both XPath 2.0 and XPath 1.0. The idea
here is to emulate the behavior of SQL nulls. It allows you to write, for
example

book[min((@net-price, @gross-price)) > 10.00]

with the predicate evaluating to false if neither attribute is present. This
is consistent with many other operators and functions.

In XPath 1.0, 

   book[(@net-price + @discount) div 2 > 10.00]

is not an error, and it's not obvious that 

   book[avg((@net-price, @discount)) > 10.00]

should be any different.

I fully accept that the alternative design you propose is feasible; it's a
value judgement which is better.

Michael Kay