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 In Section 5.5, there is a definition of "decimal-format". The structure here is similar to that found in CLDR/LDML [1], which is a very good thing. However, there are additional number related items in that section of LDML, particularly related to decimal, percent, scientific, and currency formatting. [1] http://www.unicode.org/reports/tr35/tr35-numbers.html#Number_Elements This is an I18N WG comment.
This bug applies equally well to the XPath and XQuery Functions and Operators 3.1 specification.
This was discussed at the XSL WG meeting today, but without a definitive conclusion. We noted some of the problems: (a) issues related to the logistics of changing our specs at this point in the development process (b) issues related to backwards compatibility (c) differences of fitting new features into the way we currently subdivide functionality: decimal formats and pictures for fractional numbers, xsl:number and format-integer for integers. (d) since XSLT and XQuery are Turing-complete languages, we feel there are some formatting issues that are best tackled by user-written functions rather than by declarative mechanisms. Many WG members felt that currency formatting fell into that category. (e) some number formatting seems to require the output to include markup rather than being merely a string of characters (e.g superscripts, or "boxing" of roman numerals). Such formatting is beyond the scope of our current functions and should remain so. We left the discussion with actions to examine whether there were features in TR35 that could (and should) be integrated into our current structure of format-number()/format-integer() without excessive disruption.
Personal observation: Looking at the comment "particularly decimal, percent, scientific, and currency formatting", let's look at these in turn. 1. decimal formatting: this is definitely within the scope of xsl:decimal-format and the format-number function. Comparing with TR35, section 2.4 in particular, some omissions are: 1.1 pattern types: this seems to be LDML syntax to indicate that different formatting rules should be used for numbers in different ranges. The natural way to do this in XPath is with conditionals, for example format-number($x, if ($x gt 1000) then $pic1 else $pic2) I don't think we need a conditional syntax within the picture itself. 1.2 At least/range We would expect users to handle such things using XPath conditional logic, e.g. if ($x gt 100) then ">100" else format-number($x,...) 1.3 Padding (see 3.6) One thing we don't have in format-number, and which users often request, is padding. When we get an opportunity to enhance the specification, I would suggest adding a pad-character attribute to the decimal-format (default absent), and allowing pad characters to appear at the start or end of the picture, in place of 0/#, to indicate position that should be padded if not occupied by a significant digit. E.g. if "_" is the pad character, and "__0" is the picture, then 23 is output as "_23". (This is needed only when producing text output in fixed-width fonts. OK, that's old-fashioned. But it's still done). Should allow the minus sign before or after the padding. 1.4 Scientific notation (see 3.4) In 3.0 we have added support for "programming notation" (1.3e6) but not for true scientific notation 1.234 x 10^3. The problem here is superscripts, which typically require markup, while format-number() can only output strings. I think that in practice, an adequate solution to this rather specialized requirement is to take the output in "programming notation" and post-process it to generate the markup. This is well within the capability of XSLT and XQuery programmers. 1.5 Rounding (see 3.7) format-number() prescribes round-half-to-even. Other rounding algorithms can be achieved by applying other functions before formatting. I think we should keep rounding and formatting separate. 2. Percent I can't see what we're supposed to be missing in this area: format-number() seems well aligned with TR35 here. 3. Scientific Altready covered, see 1.4 above 4. Currency At present XSLT does nothing in this area. Presumably users are reasonably happy to code this up using their own functions. If we did something, I would want to keep it well separate (a new function format-currency(), perhaps). If this is to offer added value beyond users formatting the output themselves, then the added value would be knowledge of what currency formats are conventional in different locales. So it would be something like format-currency(123.45, "EUR", "FR") to say "format the value EUR123.45 in the form that is conventional in France".
Created attachment 1579 [details] Revised v3 proposal for streamable stylesheet functions (.odt)
Sorry, bugzilla's dreadful dialog structure strikes again - added the attachment to the wrong bug.
In response to this comment, the XSL WG attempted to identify where there were differences between our current facilities and those described in TR35, and reviewed the opportunities for further alignment. See the following member-only links: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Feb/0002.html https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Mar/0010.html For many of the missing features, the WG felt that XPath functions such as format-number() and format-integer() will usually used within the context of a Turing-complete programming language such as XSLT or XQuery, or at any rate a language offering conditional expressions, such as XPath. Facilities such as using different grouping positions based on the magnitude of the number could therefore be readily achieved using the facilities of the host language, and it would be a mistake to duplicate this functionality within the micro-language used for defining numeric pictures. (Indeed, given a free hand, we would probably drop some existing features such as support for percent and per-mille if we were starting today.) We did identify some features that are often requested by users, for example padding, which we would be favourably inclined to add to the spec if we were at a different stage of development; but since all these features have relatively straightforward workarounds by writing user-defined functions to achieve the task, we did not feel that these features were sufficiently urgent to justify delaying the progression of XSLT 3.0 to CR, or XPath 3.1 to PR. At the current stage of development we need to be brutal in rejecting "good ideas" that are not essential to completion. I am therefore closing this on the WG's behalf as "LATER", meaning that if we ever get the charter and resources to produce another version of XSLT or XPath, the comment will be taken into account as a candidate for inclusion in the requirements for that version. We thank the I18N group for drawing our attention to the opportunities in this area, and we are hopeful that you will accept our decision of the disposition.