This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Our results differ from the expected results for text numberformat60. Part of the test includes format-number(1E100 div 3,'#####################') with the corresponding part of the expected result being 3333333333333333224453896013722304246165110619355184909726539264904319486405759542029132894851563520 Our result for this part of the test is 3333333333333333000000000000000000000000000000000000000000000000000000000000000000000000000000000000 which is the conversion to a string of the double value with bit pattern (expressed as a long) 6095730106324201297. Is the expected result correct?
The expected result given certainly can't be justified by the spec; yours is much better. (The spec does say the value should be converted to decimal, rather than directly to string. For some reaons the Java double-to-BigDecimal is producing this random set of noise, which is defeating Saxon's attempt to remove insignificant non-zero trailers.) I'll change the test to use your result.
Confirmed fixed.