This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://www.w3.org/TR/xslt-30/#defining-decimal-format decimal-format seems to mirror much of what CLDR provides in terms of base data for formatting numbers in XSL-FO. Would it be useful to provide an informative reference to CLDR as a source for filling in this structure? Thinking out loud, would it be useful to allow direct reference to a language/locale in this structure as a shorthand for using implementation-specific locale data (often based on CLDR). This is an I18N WG comment.
This bug applies equally well to the XPath and XQuery Functions and Operators 3.1 specification.
Personal response: Thanks for drawing our attention to th CLDR facilities for number formatting, which indeed have much in common with what XSLT and XQuery provide in the format-number() function. For reference, http://www.unicode.org/reports/tr35/tr35-37/tr35-numbers.html#Number_Format_Patterns As far as I can tell, they have similar origins in Java 1.1, but have since diverged a little, for example XSLT decided that ignoring the negative number pattern except for the prefix and suffix was a bug to be fixed, whereas Java and CLDR decided that it was a feature to be documented. My immediate reaction was that the only way we could usefully reference CLDR, given that the specs have diverged, is in the form of a health warning that there are differences. We could perhaps try and do the research needed to establish exactly what these differences are. Since format-number() adds exponential notation in XPath 3.1, we still have the opportunity to check that it does so in a way that is consistent with CLDR, and change it if necessary. (For example, I note that CLDR provides a way to request a "+" sign in a positive exponent, whereas XPath 3.1 format-number() does not.) We could also -- perhaps for a future release -- review whether there are facilities in CLDR that could be usefully added to format-number(). Currency formatting is one example. Rounding is another, though I would defend the decision to separate rounding from formatting. Note also that XSLT, for reasons I have never fully understood and wouldn't try to defend, has two separate mechanisms for number formatting: xsl:number (for formatting integers, including use of other number systems such as Roman and Hebrew), and format-number() for formatting floating point numbers, always in decimal notation, though with the ability to choose the digit family). xsl:number allows locale-based formatting, fomat-number() does not. We've tried to converge these a little with the introduction of format-integer(), but this is far from complete.
The Working Group reviewed whether are are specific formatting capabilities in CLDR that we would wish to add to format-number(). We discussed currency formatting. The general view was that if we provide anything in this area, it should be separate from format-number. Some WG members felt that existing practice, where it is done with user-defined functions, was an entirely adequate solution; certainly we do not recall users asking for facilities in this area. The WG felt that rounding is best handled separately from formatting. Although we do not provide all conceivable rounding algorithms in the function library, it is not difficult for users or third parties to implement additional functions in this area. We noted one small omission in the new facilities for exponential formatting; we don't allow the exponent to have a plus sign. The main purpose of exponential formatting is to generate numbers in formats required by other software specifications, and we are not aware of any that make a plus sign mandatory, so we doubt this will be a problem. Remedying the omission at the current development stage is a little tricky because we would need to add a "plus sign" to the list of decimal format properties, and reclassify the "minus sign" so it can appear in a picture; this would further confuse the issue whereby separate pictures are used for negative and positive numbers. We could consider, in a future release, the possibility of "importing" a decimal format from locale data rather than defining it in fine detail in the stylesheet. This isn't straightforward because of the interaction between characters used in the picture and characters used in the formatted output. (The picture, for example, must use the same digit family as the formatted output.) I'm closing this on behalf of the WG with the disposition "later", meaning that we will come back to it if we ever start work on a future version of the language. XSL WG hopes that this disposition is acceptable to I18N, and if so, requests that you close the bug.
The Internationalization WG has carefully reviewed your response as well as responses to this message: https://lists.w3.org/Archives/Public/public-qt-comments/2015Feb/0110.html I was tasked [I18N-ACTION-410] with replying to this issue to indicate that we are not satisfied by a resolution of "later". We will NOT have any objection, formal or otherwise, to your progressing XSLT30 and feel that this issue is relatively minor. However, we ask that you "NOTE" this issue in your pending CR transition. We recognize that more could have been done (and could have been done sooner) and wish we had reviewed earlier drafts. However, it's also the case that we had no contact from QT for quite some time before the LCWD that produced this comment. In the future, we hope to work with your WG to re-establish better regular communication for any future work that may occur. -- This decision was taken in our teleconference today (2015-02-26) and minuted here: http://www.w3.org/2015/02/26-i18n-minutes.html#item07