From 6eba3ceac41bb06def5c0a4fac02987778466561 Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Tue, 22 Aug 2023 13:18:21 +0200 Subject: [PATCH 01/15] add some capabilities for the builtin functions --- spec/registry.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/spec/registry.md b/spec/registry.md index 6962fa7d29..1c8ee78bc8 100644 --- a/spec/registry.md +++ b/spec/registry.md @@ -186,3 +186,17 @@ which only expects the `accord` option: let $obj = {$object :noun case=nominative} {You see {$color :adjective article=indefinite accord=$obj} {$obj}!} + +## Built-in Registry + +As hinted in the example above, implementations may provide built-in functions to their users in order to perform common operations in a standardized manner instead of having to rely on custom functions for everything. The working group agrees that these builtins provided by implementations should expose the following capabilities to their users: + +* Ability to format the following types of data in a locale-sensitive manner: + * Dates and times + * Numbers + * Lists +* Ability to select for the following types of information in a locale-sensitive manner: + * Plural rules + * Gender + +The co-located `registry.xml` file aims to define such a set of built-in functions, inspired by the design of the ICU4X and JavaScript's ECMA-402 APIs. \ No newline at end of file From 92512a4ce03625d10010e567e9cdcb58e91dab31 Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Tue, 22 Aug 2023 18:49:47 +0200 Subject: [PATCH 02/15] move exploration about builtins Move the exploratory idea about the builtin registry from the spec/registry.md file to the exploration directory and apply some reviews. --- .../0001-builtin-registry-capabilities.md | 52 +++++++++++++++++++ spec/registry.md | 14 ----- 2 files changed, 52 insertions(+), 14 deletions(-) create mode 100644 exploration/0001-builtin-registry-capabilities.md diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md new file mode 100644 index 0000000000..0ca83843e1 --- /dev/null +++ b/exploration/0001-builtin-registry-capabilities.md @@ -0,0 +1,52 @@ +# Capabilities for built-ins + +
+ Metadata +
+
Contributors
+
@ryzokuken
+
First proposed
+
2023-08-22
+
Pull Request
+
#457
+
+
+ +## Objective + +Document the capabilities that the set of built-in functions would expose to the user in order to ensure it can be designed in the most minimalistic way that would still cater to the most pressing requirements, partly inspired by ICU4X anbd JavaScript's Intl API and backwards-compatible with MF1 in ICU4J. + +## Background + +Users have the ability to specify and call arbitrary custom functions in their messages thanks to the function registry. +That said, there are a number of common i18n operations that are quite universal and there's a lot of value in standardizing the usage of these common operations across the ecosystem. +This document aims to list down the basic capabilities for developers that such a set of standard built-in functions MUST provide. + +## Use-Cases + +From formatting date and time values to performing selection based on plural rules, the use cases for a minimal set of common tools standardized across implementations are virtually everywhere. While a number of applications might require more complex functions with custom logic, a decently designed set of built-in functions could significantly lower the barrier of entry as well as the need to write many custom functions. + +## Requirements + +TBD + +## Constraints + +TBD + +## Proposed Design + +All conforming implementations of this specification MUST provide a set of built-in functions, which allows the developers to perform the following operations: + +* Formatting the following types of data in a locale-sensitive manner: + * Dates and times + * Numbers + * Lists +* Selecting between pattern strings in a locale-sensitive manner based on: + * String equality + * Plural rules + * Ordinality + +## Alternatives Considered + +TBD \ No newline at end of file diff --git a/spec/registry.md b/spec/registry.md index 1c8ee78bc8..6962fa7d29 100644 --- a/spec/registry.md +++ b/spec/registry.md @@ -186,17 +186,3 @@ which only expects the `accord` option: let $obj = {$object :noun case=nominative} {You see {$color :adjective article=indefinite accord=$obj} {$obj}!} - -## Built-in Registry - -As hinted in the example above, implementations may provide built-in functions to their users in order to perform common operations in a standardized manner instead of having to rely on custom functions for everything. The working group agrees that these builtins provided by implementations should expose the following capabilities to their users: - -* Ability to format the following types of data in a locale-sensitive manner: - * Dates and times - * Numbers - * Lists -* Ability to select for the following types of information in a locale-sensitive manner: - * Plural rules - * Gender - -The co-located `registry.xml` file aims to define such a set of built-in functions, inspired by the design of the ICU4X and JavaScript's ECMA-402 APIs. \ No newline at end of file From 63cd2cab99e682303bb00d81803ac0fd76ceee2d Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Mon, 28 Aug 2023 15:43:14 +0200 Subject: [PATCH 03/15] apply suggestions --- exploration/0001-builtin-registry-capabilities.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index 0ca83843e1..ab23cd92fb 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -8,13 +8,13 @@
First proposed
2023-08-22
Pull Request
-
#457
+
#457
## Objective -Document the capabilities that the set of built-in functions would expose to the user in order to ensure it can be designed in the most minimalistic way that would still cater to the most pressing requirements, partly inspired by ICU4X anbd JavaScript's Intl API and backwards-compatible with MF1 in ICU4J. +Document the capabilities that the set of built-in functions would expose to the user in order to ensure it can be designed in the most minimalistic way that would still cater to the most pressing requirements, partly inspired by ICU4X and JavaScript's Intl API and backwards-compatible with MF1 in ICU4J. ## Background From edcf00420253e447ea0532be677846ce15de2d5f Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Tue, 29 Aug 2023 21:22:55 +0200 Subject: [PATCH 04/15] add status to capabilities proposal --- exploration/0001-builtin-registry-capabilities.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index ab23cd92fb..9dd8e77152 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -1,5 +1,7 @@ # Capabilities for built-ins +Status: **Proposed** +
Metadata
From 1a009c43190b5b1d09c4221bbd2eb91c89f7ec72 Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Thu, 31 Aug 2023 13:39:18 +0200 Subject: [PATCH 05/15] manually run prettier on file --- .../0001-builtin-registry-capabilities.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index 9dd8e77152..0b077d60c8 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -40,15 +40,15 @@ TBD All conforming implementations of this specification MUST provide a set of built-in functions, which allows the developers to perform the following operations: -* Formatting the following types of data in a locale-sensitive manner: - * Dates and times - * Numbers - * Lists -* Selecting between pattern strings in a locale-sensitive manner based on: - * String equality - * Plural rules - * Ordinality +- Formatting the following types of data in a locale-sensitive manner: + - Dates and times + - Numbers + - Lists +- Selecting between pattern strings in a locale-sensitive manner based on: + - String equality + - Plural rules + - Ordinality ## Alternatives Considered -TBD \ No newline at end of file +TBD From c33e0264f1048d9911d630fcd8f0cd226a35cbe0 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Thu, 31 Aug 2023 11:42:31 +0000 Subject: [PATCH 06/15] style: Apply Prettier --- .../0001-builtin-registry-capabilities.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index 0b077d60c8..fac34c5f1c 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -40,14 +40,14 @@ TBD All conforming implementations of this specification MUST provide a set of built-in functions, which allows the developers to perform the following operations: -- Formatting the following types of data in a locale-sensitive manner: - - Dates and times - - Numbers - - Lists -- Selecting between pattern strings in a locale-sensitive manner based on: - - String equality - - Plural rules - - Ordinality +- Formatting the following types of data in a locale-sensitive manner: + - Dates and times + - Numbers + - Lists +- Selecting between pattern strings in a locale-sensitive manner based on: + - String equality + - Plural rules + - Ordinality ## Alternatives Considered From e921309200e2c198486d9be223b8d4dba58a071a Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Fri, 1 Sep 2023 17:20:09 +0200 Subject: [PATCH 07/15] Update exploration/0001-builtin-registry-capabilities.md Co-authored-by: Eemeli Aro --- exploration/0001-builtin-registry-capabilities.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index fac34c5f1c..c3a6cf9217 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -46,8 +46,8 @@ All conforming implementations of this specification MUST provide a set of - Lists - Selecting between pattern strings in a locale-sensitive manner based on: - String equality - - Plural rules - - Ordinality + - Plural rules + - Ordinality ## Alternatives Considered From 0c26a646af326625f31d5f9ddf8b2cfee44c63b8 Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Mon, 4 Sep 2023 16:55:06 +0200 Subject: [PATCH 08/15] add more details --- exploration/0001-builtin-registry-capabilities.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index c3a6cf9217..304225eae3 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -30,11 +30,13 @@ From formatting date and time values to performing selection based on plural rul ## Requirements -TBD +Implementations are not required to implement and expose all the built-in functions that would result from this initiative. However, they are required to strictly stick to the standardized interface for the functions they do expose. ## Constraints -TBD +Like many standardized APIs out there, the biggest constraint on the resulting set of built-in functions would be that until we decide to make another major update to MessageFormat, we'd not be able to make breaking changes to the function interfaces since that would invalidate the promise of a consistent API across implementations and versions. + +Another constraint is that since MessageFormat would be used alongside other internationalization features in many programming environments, the final interface should be somewhat consistent to reduce developer confusion. ## Proposed Design @@ -51,4 +53,4 @@ All conforming implementations of this specification MUST provide a set of ## Alternatives Considered -TBD +The alternative would be to not include any built-in functions, essentially outsourcing the task of curating and maintaining commonly used functions to the ecosystem. The details of how this could work out in practice are unclear. From 99ba72e01ebde0450206df36e6622de42a0c711e Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Wed, 6 Sep 2023 12:26:26 +0200 Subject: [PATCH 09/15] various improvements + apply suggestions --- .../0001-builtin-registry-capabilities.md | 20 +++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index 304225eae3..2bc752c03c 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -1,4 +1,4 @@ -# Capabilities for built-ins +# Capabilities for built-in registry Status: **Proposed** @@ -16,31 +16,35 @@ Status: **Proposed** ## Objective -Document the capabilities that the set of built-in functions would expose to the user in order to ensure it can be designed in the most minimalistic way that would still cater to the most pressing requirements, partly inspired by ICU4X and JavaScript's Intl API and backwards-compatible with MF1 in ICU4J. +Document the capabilities that the set of _built-in functions_ included in the default _built-in registry_ would expose to the user in order to ensure it can be designed in the most minimalistic way that would still cater to the most pressing requirements, partly inspired by ICU4X and JavaScript's Intl API and backwards-compatible with MF1 in ICU4J. ## Background Users have the ability to specify and call arbitrary custom functions in their messages thanks to the function registry. That said, there are a number of common i18n operations that are quite universal and there's a lot of value in standardizing the usage of these common operations across the ecosystem. -This document aims to list down the basic capabilities for developers that such a set of standard built-in functions MUST provide. +This document aims to list down the basic capabilities that need to be provided to developers by a _built-in registry_. ## Use-Cases -From formatting date and time values to performing selection based on plural rules, the use cases for a minimal set of common tools standardized across implementations are virtually everywhere. While a number of applications might require more complex functions with custom logic, a decently designed set of built-in functions could significantly lower the barrier of entry as well as the need to write many custom functions. +From formatting date and time values to performing selection based on plural rules, the use cases for a minimal set of common tools standardized across implementations are virtually everywhere. +While a number of applications might require more complex functions with custom logic, a decently designed set of _built-in functions_ could significantly lower the barrier of entry as well as the need to write and maintain many custom functions. ## Requirements -Implementations are not required to implement and expose all the built-in functions that would result from this initiative. However, they are required to strictly stick to the standardized interface for the functions they do expose. +Implementations are required to implement and expose the entire _built-in registry_ that would provide the capabilities in this document. ## Constraints -Like many standardized APIs out there, the biggest constraint on the resulting set of built-in functions would be that until we decide to make another major update to MessageFormat, we'd not be able to make breaking changes to the function interfaces since that would invalidate the promise of a consistent API across implementations and versions. +Like many standardized APIs out there, the biggest constraint on the resulting set of _built-in functions_ would be that until we decide to make another major update to MessageFormat, we'd not be able to make breaking changes to the function signatures since that would invalidate the promise of a consistent API across implementations and versions. Another constraint is that since MessageFormat would be used alongside other internationalization features in many programming environments, the final interface should be somewhat consistent to reduce developer confusion. ## Proposed Design -All conforming implementations of this specification MUST provide a set of built-in functions, which allows the developers to perform the following operations: +The **_built-in registry_** is the set of _functions_, together with their options, that are present in every implementation. +Implementations MUST provide each of the built-in functions defined in the _built-in registry_, including all of the options. +They MAY include additional options, although implementers are cautioned to avoid options which might conflict with future standardization. +These include the following capabilities: - Formatting the following types of data in a locale-sensitive manner: - Dates and times @@ -53,4 +57,4 @@ All conforming implementations of this specification MUST provide a set of ## Alternatives Considered -The alternative would be to not include any built-in functions, essentially outsourcing the task of curating and maintaining commonly used functions to the ecosystem. The details of how this could work out in practice are unclear. +The alternative would be to not include any _built-in functions_, essentially outsourcing the task of curating and maintaining commonly used functions to the ecosystem. \ No newline at end of file From 4a52ec8719daa9ff9603a895bffef4fa83937650 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 6 Sep 2023 10:27:18 +0000 Subject: [PATCH 10/15] style: Apply Prettier --- exploration/0001-builtin-registry-capabilities.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index 2bc752c03c..6369412635 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -57,4 +57,4 @@ These include the following capabilities: ## Alternatives Considered -The alternative would be to not include any _built-in functions_, essentially outsourcing the task of curating and maintaining commonly used functions to the ecosystem. \ No newline at end of file +The alternative would be to not include any _built-in functions_, essentially outsourcing the task of curating and maintaining commonly used functions to the ecosystem. From 62406f156e54fabb7d9466c4465972d498c06de4 Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Wed, 6 Sep 2023 14:30:26 +0200 Subject: [PATCH 11/15] two more suggestions --- exploration/0001-builtin-registry-capabilities.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index 6369412635..4a8bd703f7 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -42,7 +42,8 @@ Another constraint is that since MessageFormat would be used alongside other int ## Proposed Design The **_built-in registry_** is the set of _functions_, together with their options, that are present in every implementation. -Implementations MUST provide each of the built-in functions defined in the _built-in registry_, including all of the options. +Implementations MUST provide each of the _built-in functions_ defined in the _built-in registry_, including all of the options. +Note that the final output of these functions is still implementation-defined. They MAY include additional options, although implementers are cautioned to avoid options which might conflict with future standardization. These include the following capabilities: @@ -58,3 +59,4 @@ These include the following capabilities: ## Alternatives Considered The alternative would be to not include any _built-in functions_, essentially outsourcing the task of curating and maintaining commonly used functions to the ecosystem. +Another alternative would be to specify the signatures of the functions in a default registry for interoperability between implementations but not require implementations to implement all of them. From 185707b8c7f329efcd13fe0ccf5b05b780819690 Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Fri, 8 Sep 2023 18:01:54 +0200 Subject: [PATCH 12/15] break lines and adopt some suggestions --- .../0001-builtin-registry-capabilities.md | 39 ++++++++++++------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index 4a8bd703f7..fc7c3a3044 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -16,35 +16,47 @@ Status: **Proposed** ## Objective -Document the capabilities that the set of _built-in functions_ included in the default _built-in registry_ would expose to the user in order to ensure it can be designed in the most minimalistic way that would still cater to the most pressing requirements, partly inspired by ICU4X and JavaScript's Intl API and backwards-compatible with MF1 in ICU4J. +Document the set of capabilities needed by the _built-in registry_ in order to provide a reasonably complete set of +functions. +This includes ensuring sufficient compatibility with the various functions available in ICU4X, JavaScript `Intl` as well +as MessageFormat v1. ## Background Users have the ability to specify and call arbitrary custom functions in their messages thanks to the function registry. -That said, there are a number of common i18n operations that are quite universal and there's a lot of value in standardizing the usage of these common operations across the ecosystem. -This document aims to list down the basic capabilities that need to be provided to developers by a _built-in registry_. +That said, there are a number of common i18n operations that are quite universal and there's a lot of value in +standardizing the usage of these common operations across the ecosystem. +This document aims to list down the basic capabilities that implementations need to be provide in a _built-in registry_. ## Use-Cases -From formatting date and time values to performing selection based on plural rules, the use cases for a minimal set of common tools standardized across implementations are virtually everywhere. -While a number of applications might require more complex functions with custom logic, a decently designed set of _built-in functions_ could significantly lower the barrier of entry as well as the need to write and maintain many custom functions. +From formatting date and time values to performing selection based on plural rules, the use cases for a minimal set of +common tools standardized across implementations are virtually everywhere. +While a number of applications might require more complex functions with custom logic, a well-provisioned default +registry could significantly lower the barrier of entry as well as the need to write and maintain many custom functions. ## Requirements -Implementations are required to implement and expose the entire _built-in registry_ that would provide the capabilities in this document. +Implementations are required to implement and expose the entire _built-in registry_ that would provide the capabilities +in this document. ## Constraints -Like many standardized APIs out there, the biggest constraint on the resulting set of _built-in functions_ would be that until we decide to make another major update to MessageFormat, we'd not be able to make breaking changes to the function signatures since that would invalidate the promise of a consistent API across implementations and versions. +Like many standardized APIs out there, the biggest constraint on the resulting _built-in registry_ would be that until +we decide to make another major update to MessageFormat, we'd not be able to make breaking changes to the function +signatures since that would invalidate the promise of a consistent API across implementations and versions. -Another constraint is that since MessageFormat would be used alongside other internationalization features in many programming environments, the final interface should be somewhat consistent to reduce developer confusion. +Another constraint is that since MessageFormat would be used alongside other internationalization features in many +programming environments, the final interface should be somewhat consistent to reduce developer confusion. ## Proposed Design -The **_built-in registry_** is the set of _functions_, together with their options, that are present in every implementation. -Implementations MUST provide each of the _built-in functions_ defined in the _built-in registry_, including all of the options. -Note that the final output of these functions is still implementation-defined. -They MAY include additional options, although implementers are cautioned to avoid options which might conflict with future standardization. +The **_built-in registry_** is the set of functions, together with their options, that are present in every +implementation. +Implementations MUST provide each of the functions defined in the _built-in registry_, including all of the options. +The ouptut of each function is implementation-defined. +They MAY include additional options, although implementers are cautioned to avoid options which might conflict with +future standardization. These include the following capabilities: - Formatting the following types of data in a locale-sensitive manner: @@ -58,5 +70,6 @@ These include the following capabilities: ## Alternatives Considered -The alternative would be to not include any _built-in functions_, essentially outsourcing the task of curating and maintaining commonly used functions to the ecosystem. +The alternative would be to not include a _built-in registry_, essentially outsourcing the task of curating and +maintaining commonly used functions to the ecosystem. Another alternative would be to specify the signatures of the functions in a default registry for interoperability between implementations but not require implementations to implement all of them. From 588119385c99e0dfe61656a75aec8f5b01272be7 Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Fri, 8 Sep 2023 19:21:40 +0200 Subject: [PATCH 13/15] improve alternatives --- .../0001-builtin-registry-capabilities.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index fc7c3a3044..babca628e3 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -70,6 +70,18 @@ These include the following capabilities: ## Alternatives Considered -The alternative would be to not include a _built-in registry_, essentially outsourcing the task of curating and -maintaining commonly used functions to the ecosystem. -Another alternative would be to specify the signatures of the functions in a default registry for interoperability between implementations but not require implementations to implement all of them. +The working group has considered a number of ways to address core functionality. These include: + +**No default registry** Each implementation would be free to define its own set of functions and options for each. +- (+) Each implementation would be able to define functions and options according to existing I18N APIs which would be +familiar to users in that language or runtime +- (-) Messages would not be portable between implementations +- (-) Users would have to learn the variations between implementations +- (-) Tooling would have to be adjusted for each variation + +**Informative registry** The default registry could be made informative with implementations allowed to pick-and-choose +(or ignore) entries. +This would provide better interoperability for implementations claiming to implement the default registry, while +allowing platform-specific variation. + +**Non-extensible registry entries** Like this design, but not allowing implementation specific options. From 4ebad87d37651e78d7968b8f33a8726798804674 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Fri, 8 Sep 2023 17:22:21 +0000 Subject: [PATCH 14/15] style: Apply Prettier --- exploration/0001-builtin-registry-capabilities.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index babca628e3..4a435e151b 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -73,8 +73,9 @@ These include the following capabilities: The working group has considered a number of ways to address core functionality. These include: **No default registry** Each implementation would be free to define its own set of functions and options for each. + - (+) Each implementation would be able to define functions and options according to existing I18N APIs which would be -familiar to users in that language or runtime + familiar to users in that language or runtime - (-) Messages would not be portable between implementations - (-) Users would have to learn the variations between implementations - (-) Tooling would have to be adjusted for each variation From 96c8c433e0f277fd68ff8ad1473fe6e87e68f44f Mon Sep 17 00:00:00 2001 From: Ujjwal Sharma Date: Thu, 21 Sep 2023 00:47:11 +0530 Subject: [PATCH 15/15] apply more suggestions --- .../0001-builtin-registry-capabilities.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/exploration/0001-builtin-registry-capabilities.md b/exploration/0001-builtin-registry-capabilities.md index 4a435e151b..2a29ed5a3a 100644 --- a/exploration/0001-builtin-registry-capabilities.md +++ b/exploration/0001-builtin-registry-capabilities.md @@ -40,23 +40,22 @@ registry could significantly lower the barrier of entry as well as the need to w Implementations are required to implement and expose the entire _built-in registry_ that would provide the capabilities in this document. -## Constraints +The names of functions and associated options defined by the registry **MUST** remain unchanged for the sake of +compatibility, interoperability and general API stability. -Like many standardized APIs out there, the biggest constraint on the resulting _built-in registry_ would be that until -we decide to make another major update to MessageFormat, we'd not be able to make breaking changes to the function -signatures since that would invalidate the promise of a consistent API across implementations and versions. +## Constraints -Another constraint is that since MessageFormat would be used alongside other internationalization features in many -programming environments, the final interface should be somewhat consistent to reduce developer confusion. +Since MessageFormat would be used alongside other internationalization features in many programming environments, the +final interface **SHOULD NOT** deviate a lot from existing APIs in order to minimize developer confusion. ## Proposed Design The **_built-in registry_** is the set of functions, together with their options, that are present in every implementation. Implementations MUST provide each of the functions defined in the _built-in registry_, including all of the options. -The ouptut of each function is implementation-defined. -They MAY include additional options, although implementers are cautioned to avoid options which might conflict with -future standardization. +The output of each function is implementation-defined. +Implementations MAY include additional options for built-in functions, although implementers are cautioned to avoid +adding options that might conflict with future standardization. These include the following capabilities: - Formatting the following types of data in a locale-sensitive manner: