[Bug 27613] [XSLT30] I18N-ISSUE-392: Decimal Format incomplete?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27613

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
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".

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 23 January 2015 09:23:48 UTC