@@ -703,8 +703,8 @@ where `resolvedSelector` is the _resolved value_ of a _selector_
703
703
and `keys` is a list of strings,
704
704
numeric selectors perform as described below.
705
705
706
- 1. Let `exact` be the JSON string representation of the numeric value of `resolvedSelector`.
707
- (See [Determining Exact Literal Match](#determining- exact-literal-match) for details)
706
+ 1. Let `exact` be the serialized representation of the numeric value of `resolvedSelector`.
707
+ (See [Exact Literal Match Serialization ](#exact-literal-match-serialization ) for details)
708
708
1. Let `keyword` be a string which is the result of [rule selection](#rule-selection) on `resolvedSelector`.
709
709
1. Let `resultExact` be a new empty list of strings.
710
710
1. Let `resultKeyword` be a new empty list of strings.
@@ -780,36 +780,31 @@ for examples.
780
780
> | 27 | `other` | 27 dní |
781
781
> | 2.4 | `many` | 2,4 dne |
782
782
783
- #### Determining Exact Literal Match
783
+ #### Exact Literal Match Serialization
784
784
785
- > [!IMPORTANT]
786
- > The exact behavior of exact literal match is currently only well defined for non-zero-filled
787
- > integer values.
788
- > Functions that use fraction digits or significant digits might work in specific
789
- > implementation-defined ways.
790
- > Users should avoid depending on these types of keys in message selection in this release.
785
+ If the numeric value of `resolvedSelector` is an integer
786
+ and none of the following options are set for `resolvedSelector`,
787
+ the serialized form of the numeric value MUST match the ABNF defined below for `integer`,
788
+ representing its decimal value:
789
+ - `minimumFractionDigits`
790
+ - `minimumIntegerDigits`
791
+ - `minimumSignificantDigits`
792
+ - `maximumSignificantDigits`
793
+ - `notation`
794
+ - `style`
791
795
796
+ ```abnf
797
+ integer = "0" / ["-"] ("1"-"9") *DIGIT
798
+ ```
792
799
793
- Number literals in the MessageFormat 2 syntax use the
794
- [format defined for a JSON number](https://www.rfc-editor.org/rfc/rfc8259#section-6).
795
- A `resolvedSelector` exactly matches a numeric literal `key`
796
- if, when the numeric value of `resolvedSelector` is serialized using the format for a JSON number,
797
- the two strings are equal.
800
+ Otherwise, the serialized form of the numeric value is implementation-defined.
798
801
799
- > [!NOTE]
800
- > The above description of numeric matching contains
801
- > [open issues](https://github.com/unicode-org/message-format-wg/issues/675)
802
- > in the Technical Preview, since a given numeric value might be formatted in
803
- > several different ways under RFC8259
804
- > and since the effect of formatting options, such as the number of fraction
805
- > digits or significant digits, is not described.
806
- > The Working Group intends to address these issues before final release
807
- > with a number of design options
808
- > [being considered](https://github.com/unicode-org/message-format-wg/pull/859).
809
- >
810
- > Users should avoid creating messages that depend on exact matching of non-integer
811
- > numeric values.
812
- > Feedback, including use cases encountered in message authoring, is strongly desired.
802
+ > [ !IMPORTANT]
803
+ > The exact behavior of exact literal match is only well defined
804
+ > for integer values without leading zeros.
805
+ > Functions that use fraction digits or significant digits
806
+ > might work in specific implementation-defined ways.
807
+ > Users should avoid depending on these types of keys in message selection.
813
808
814
809
## Date and Time Value Formatting
815
810
0 commit comments