@@ -703,8 +703,8 @@ where `resolvedSelector` is the _resolved value_ of a _selector_
703703and `keys` is a list of strings,
704704numeric selectors perform as described below.
705705
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)
7087081. Let `keyword` be a string which is the result of [rule selection](#rule-selection) on `resolvedSelector`.
7097091. Let `resultExact` be a new empty list of strings.
7107101. Let `resultKeyword` be a new empty list of strings.
@@ -780,36 +780,31 @@ for examples.
780780> | 27 | `other` | 27 dní |
781781> | 2.4 | `many` | 2,4 dne |
782782
783- #### Determining Exact Literal Match
783+ #### Exact Literal Match Serialization
784784
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`
791795
796+ ```abnf
797+ integer = "0" / ["-"] ("1"-"9") *DIGIT
798+ ```
792799
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.
798801
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.
813808
814809## Date and Time Value Formatting
815810
0 commit comments