format-number () со строкой изображения '#. ##' - PullRequest
0 голосов
/ 01 мая 2020

В течение многих лет я использовал строку изображения '#. ## "в коде XSLT 1.0 для форматирования чисел с десятичными знаками, если они имеют дробную часть, и не отображал десятичные дроби, если дробная часть отсутствует.

Saxon 6.5.5.
format-number(123.456,'#.##’)   123.46
format-number(123.000,'#.##’)   123

Но при использовании XSLT 2.0 или 3.0 у меня другое поведение.

Saxon 9.9.1.5J
format-number(123.456,'#.##’)   123.46
format-number(123.000,'#.##’)   123.0

Мне не удалось выяснить, почему в последнем случае дробная часть. https://www.w3.org/TR/xslt20/#dt -picture-string состояния:

Минимальный-дробный-размер-части устанавливается равным количеству нулевых символов git -знака, найденных в дробной части части изображения.

https://www.w3.org/TR/xpath-functions-30/#syntax строки изображения состояния:

Минимальный размер дробной части равен установить количество десятичных чисел git -семейных символов, найденных в дробной части подизображения.

И без знака нуля di git -знака и без знака десятичной дроби git -семейные символы, дробный размер должен быть равен нулю, как в случае XSLT 1.0.

Я что-то упустил

1 Ответ

1 голос
/ 01 мая 2020

Саксон применяет правило:

Если (после выполнения вышеуказанных настроек) minimum-integer-part-size и minimum-fractional-part-size оба равны нулю, тогда minimum-fractional-part-size устанавливается в 1 (один ).

XSLT 1.0 spe c для format-number () был определен в соответствии со спецификацией JDK 1.1, что было ошибкой, поскольку (a) оно всегда недооценивалось в JDK, и (b) эту версию спецификации JDK теперь почти невозможно достать. Таким образом, мы потратили много счастливых часов на написание нового spe c с нуля, в котором пытались воспроизвести JDK spe c в тех случаях, когда оно было четким и ненадежным, но заполняло пробелы. Мы учли то, как разные поставщики XSLT 1.0 интерпретировали spe c, но не рассматривали какие-либо существующие реализации (или JDK) как окончательные.

Ваш тестовый пример похож на тестовый пример numberformat228 в https://github.com/w3c/qt3tests/blob/master/fn/format-number.xml, и примечания для этого контрольного примера относятся к ошибке 29164. Запись об ошибке в https://www.w3.org/Bugs/Public/show_bug.cgi?id=29164 показывает, что приведенное выше правило было довольно поздним дополнением / замените на spe c (сентябрь 2015 г. - намного позже XPath 2.0).

Обсуждение в записи об ошибке предполагает, что основным соображением было предотвращение форматирования нуля как пустой строки. Возможно, оглядываясь назад, мы должны были рассмотреть этот случай специально.

...