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 spec for min() and max() changed between the April 2005 and Sept 2005 drafts, so that in the case where numeric promotion takes place, the function now returns the value after promotion whereas it previously returned the value before promotion. For example, given max((5, 3e0)) the function is now supposed to return the double 5e0, whereas it previously returned the integer 5. I can't see any mention of this change in the change log, and I can't find a Last Call Bugzilla entry against these functions. Did the WG actually make this change deliberately? Previously raised internally at http://lists.w3.org/Archives/Member/w3c-xsl-query/2005Oct/0051.html
It appears the change was made in response to bug 1512, which was believed at the time to be editorial only. The issue remains open.
In raising this comment I asked why the change had been made: it appears it was made in response to a comment from Joanne Tong (bug 1512) which was wrongly classified as editorial. I didn't actually express a view about whether the change was desirable. I would now argue that the previous specification is better: the value returned by max() and min() should be one of the values in the input sequence after atomization and conversion of untypedAtomic values, but before type promotion. The main reason for this is that "promotion" from decimal to double can lose precision. For example, if @default is the untypedAtomic value "0.0", the result of max((1.123456789123456789123456789, @default)) should be the value supplied in the argument, not the result of rounding this value to the nearest double.
I spoke with our developers and they think the status quo is the best way to use existing language aggregators since they normally get invoked after atomization and type promotion. With the proposed change, you would have to either preserve both values in that case and their relationship which would make the aggregators very costly to use or write a completely new aggregator which is not a good idea either. Therefore, we think that the changes done in 1512 should stay.
I've been thinking more about this, and beyond my original reasons given in comment #2, I think there are further reasons why the original spec is better. For example, consider max(($DEC, $FLT, $DBL)) where $DEC > $FLT and $DEC < $DBL. Can I get the right result in a pipelined implementation? According to the spec, all the values need to be converted to doubles before any comparisons are done. If we try to pipeline this, there's a danger of getting the wrong answer. If I start by comparing ($DEC, $FLT) by converting $DEC to float, I risk hitting a boundary case where the result of converting $DEC to float is greater than $DBL even though $DEC itself is less than $DBL (this includes the case where float($DBL) is +INF). I can avoid these errors by retaining $DEC (the original value) as the value of "max so far", and at the same time keeping track of the "highest type enountered", and at the end converting the "max so far" to the "highest type encountered". But it's extra work, and all it achieves is to give a poorer result (one that loses precision). I think it's better for the user, and easier for the implementor, if the result is always one of the numeric values actually present in the sequence: "max so far" without further conversion. Michael Rys' argument seems to be based on the ability to reuse implementations that exist in other environments. It seems to me unlikely that such implementations would accept streamed input in the right form, and therefore unlikely that a high-performance XQuery implementation would choose to use them. But perhaps he is relying on the ability of static analysis to determine the target type in advance. Unfortunately we don't all have that luxury.
On today's telephone conference the joint meeting of the XSLT and XQuery working group decided to keep the status quo and return the selected value with the type it has received during the promotion. Since you were present and expressed acceptance of the decision, we are closing this bug as won't fix.