This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2456 - Changes to min() and max()
Summary: Changes to min() and max()
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-11-04 16:35 UTC by Michael Kay
Modified: 2006-11-16 18:48 UTC (History)
0 users

See Also:


Description Michael Kay 2005-11-04 16:35:50 UTC
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
Comment 1 Michael Kay 2005-12-06 17:12:35 UTC
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.
Comment 2 Michael Kay 2005-12-13 12:04:55 UTC
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.
Comment 3 Michael Rys 2005-12-13 16:03:28 UTC
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.
Comment 4 Michael Kay 2006-01-10 14:28:32 UTC
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.  
Comment 5 Michael Rys 2006-01-10 16:37:44 UTC
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.