From 085eb23b021cc6e7de5d9970c5ff1c72d0be6150 Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Sun, 17 Nov 2024 07:26:03 -0800 Subject: [PATCH 1/5] Address "implementation-defined" literal and type values In [this thread](https://github.com/unicode-org/message-format-wg/pull/911#discussion_r1845265757) on #911, @macchiati and I discussed the handling of implementation-defined literal values and implementation-defined types. This change splits the "MAY _accept_" for these two cases, permitting both and saving us having to say "... or an implementation-defined value..." in lots of places. --- spec/registry.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/spec/registry.md b/spec/registry.md index 75c470e2e..b38420048 100644 --- a/spec/registry.md +++ b/spec/registry.md @@ -38,11 +38,23 @@ by any version of this specification for **standard** and **optional** functions. Such _options_ MUST use an implementation-specific _namespace_. -Implementations MAY _accept_ additional _option_ values for _options_ defined here. +Implementations MAY _accept_ additional literal _option_ values for _options_ defined here. However, such values might become defined with a different meaning in the future, including with a different, incompatible name or using an incompatible value space. -Supporting implementation-specific _option_ values for **standard** or **optional** functions is NOT RECOMMENDED. +Supporting implementation-specific literal _option_ values for **standard** or **optional** functions is NOT RECOMMENDED. + +Implementations MAY _accept_ implementation-defined types for _operands_ and _option_ values defined here. +Such values can be useful to users in cases where local usage and support exists +(including cases in which details vary from those defined by Unicode and CLDR). + +> For example, implementations are encouraged to _accept_ a native representation +> for currency amounts as the _operand_ in the _function_ `:currency`. +> Or a Java implementation might _accept_ a `java.time.chrono.Chronology` object +> as a value for the date/time option `calendar` +> or ICU4J's implementation might _accept_ a `com.ibm.icu.text.NumberingSystem` object +> instead of using a [Unicode Numbering System Identifier](https://cldr-smoke.unicode.org/spec/main/ldml/tr35.html#UnicodeNumberSystemIdentifier) +> for the option `numberingSystem` in _functions_ such as `:number` or `:integer`. Future versions of this specification MAY define additional _options_ and _option_ values, subject to the rules in the [Stability Policy](#stability-policy), From 6d4223b686c7ce243db8cf69e901c53c1cf74e81 Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Mon, 18 Nov 2024 06:59:20 -0800 Subject: [PATCH 2/5] Address comments, remove "literal" --- spec/registry.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/spec/registry.md b/spec/registry.md index b38420048..cc563a703 100644 --- a/spec/registry.md +++ b/spec/registry.md @@ -38,13 +38,15 @@ by any version of this specification for **standard** and **optional** functions. Such _options_ MUST use an implementation-specific _namespace_. -Implementations MAY _accept_ additional literal _option_ values for _options_ defined here. +Implementations MAY _accept_, for _options_ defined in this specification, +_option_ values which are not defined in this specification. However, such values might become defined with a different meaning in the future, including with a different, incompatible name or using an incompatible value space. -Supporting implementation-specific literal _option_ values for **standard** or **optional** functions is NOT RECOMMENDED. +Supporting implementation-specific _option_ values for **standard** or **optional** functions is NOT RECOMMENDED. -Implementations MAY _accept_ implementation-defined types for _operands_ and _option_ values defined here. +Implementations MAY _accept_, for _operands_ and _option_ values defined in this specification, +implementation-defined types. Such values can be useful to users in cases where local usage and support exists (including cases in which details vary from those defined by Unicode and CLDR). From f88c5d619e562a07a17f45b52712126c29fdae6f Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Mon, 18 Nov 2024 06:59:57 -0800 Subject: [PATCH 3/5] and => or for clarity --- spec/registry.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/registry.md b/spec/registry.md index cc563a703..aa15c9807 100644 --- a/spec/registry.md +++ b/spec/registry.md @@ -45,7 +45,7 @@ including with a different, incompatible name or using an incompatible value space. Supporting implementation-specific _option_ values for **standard** or **optional** functions is NOT RECOMMENDED. -Implementations MAY _accept_, for _operands_ and _option_ values defined in this specification, +Implementations MAY _accept_, for _operands_ or _option_ values defined in this specification, implementation-defined types. Such values can be useful to users in cases where local usage and support exists (including cases in which details vary from those defined by Unicode and CLDR). From 8cafaeeb74ec05943bad2290467919a9e8282553 Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Mon, 18 Nov 2024 07:59:21 -0800 Subject: [PATCH 4/5] Update spec/registry.md Co-authored-by: Eemeli Aro --- spec/registry.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec/registry.md b/spec/registry.md index aa15c9807..5c893cf54 100644 --- a/spec/registry.md +++ b/spec/registry.md @@ -45,8 +45,8 @@ including with a different, incompatible name or using an incompatible value space. Supporting implementation-specific _option_ values for **standard** or **optional** functions is NOT RECOMMENDED. -Implementations MAY _accept_, for _operands_ or _option_ values defined in this specification, -implementation-defined types. +Implementations MAY _accept_, for _operands_ or _options_ defined in this specification, +values with implementation-defined types. Such values can be useful to users in cases where local usage and support exists (including cases in which details vary from those defined by Unicode and CLDR). From 612751622c667228b71905540fdea2f04e56069c Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Mon, 18 Nov 2024 08:04:39 -0800 Subject: [PATCH 5/5] Address comment via a rewrite of the example --- spec/registry.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/spec/registry.md b/spec/registry.md index 5c893cf54..14d528b26 100644 --- a/spec/registry.md +++ b/spec/registry.md @@ -50,13 +50,14 @@ values with implementation-defined types. Such values can be useful to users in cases where local usage and support exists (including cases in which details vary from those defined by Unicode and CLDR). -> For example, implementations are encouraged to _accept_ a native representation -> for currency amounts as the _operand_ in the _function_ `:currency`. -> Or a Java implementation might _accept_ a `java.time.chrono.Chronology` object -> as a value for the date/time option `calendar` -> or ICU4J's implementation might _accept_ a `com.ibm.icu.text.NumberingSystem` object -> instead of using a [Unicode Numbering System Identifier](https://cldr-smoke.unicode.org/spec/main/ldml/tr35.html#UnicodeNumberSystemIdentifier) -> for the option `numberingSystem` in _functions_ such as `:number` or `:integer`. +> For example: +> - Implementations are encouraged to _accept_ some native representation +> for currency amounts as the _operand_ in the _function_ `:currency`. +> - A Java implementation might _accept_ a `java.time.chrono.Chronology` object +> as a value for the _date/time override option_ `calendar` +> - ICU4J's implementation might _accept_ a `com.ibm.icu.text.NumberingSystem` object +> instead of using a [Unicode Numbering System Identifier](https://cldr-smoke.unicode.org/spec/main/ldml/tr35.html#UnicodeNumberSystemIdentifier) +> for the option `numberingSystem` in _functions_ such as `:number` or `:integer`. Future versions of this specification MAY define additional _options_ and _option_ values, subject to the rules in the [Stability Policy](#stability-policy),