From 56f39a02612b3e3a6cd7e48978817360dc243351 Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Thu, 22 Feb 2024 11:50:44 -0800 Subject: [PATCH 1/2] Address #683: make registry data model non-TP This clarifies the status of the registry data model as experimental. --- spec/registry.md | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/spec/registry.md b/spec/registry.md index b8ababafe7..a5f94a31b0 100644 --- a/spec/registry.md +++ b/spec/registry.md @@ -2,7 +2,7 @@ Implementations and tooling can greatly benefit from a structured definition of formatting and matching functions available to messages at runtime. -The _registry_ is a mechanism for storing such declarations in a portable manner. +This specification is intended to provide a mechanism for storing such declarations in a portable manner. ## Goals @@ -30,12 +30,21 @@ in order to support the following goals and use-cases: _This section is normative._ To be conformant with MessageFormat 2.0, an implementation MUST implement -all of the formatting and selection _functions_ described in the default registry, -including all of the _options_ and _option_ values, _operands_ and outputs -described by the default registry. +the _functions_/_selectors_, _options_ and _option_ values, _operands_ and outputs +described in the section [Default Registry](#default-registry) below. -Implementations are not required to provide a registry nor to read or interpret -a copy of this registry in order to be conformant. +Implementations MAY implement additional _functions_ or additional _options_. +In particular, implementations are encouraged to provide feedback on proposed +_options_ and their values. + +> [!IMPORTANT] +> In the Tech Preview, the [registry data model](#registry-data-model) should +> be regarded as experimental. +> Changes to the format are expected during this period. +> Feedback on the registry's format and implementation is encouraged! + +Implementations are not required to provide a machine-readable registry +nor to read or interpret the registry data model in order to be conformant. The MessageFormat 2.0 Registry was created to describe the core set of formatting and selection _functions_, @@ -63,6 +72,9 @@ a registry to support localization tooling. _This section is non-normative._ +> [!IMPORTANT] +> This part of the specification is not part of the Tech Preview. + The registry contains descriptions of function signatures. [`registry.dtd`](./registry.dtd) describes its data model. @@ -258,6 +270,10 @@ which only expects the `accord` option: # Default Registry +> [!IMPORTANT] +> That part of the specification is part of the Tech Preview +> and is **_NORMATIVE_**. + This section describes the functions which each implementation MUST provide to be conformant with this specification. From ac4bbbc2c54f10b3cdc721714f6d2ab442ac2222 Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Thu, 22 Feb 2024 12:25:03 -0800 Subject: [PATCH 2/2] Apply suggestions from code review 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 a5f94a31b0..b828be6247 100644 --- a/spec/registry.md +++ b/spec/registry.md @@ -30,7 +30,7 @@ in order to support the following goals and use-cases: _This section is normative._ To be conformant with MessageFormat 2.0, an implementation MUST implement -the _functions_/_selectors_, _options_ and _option_ values, _operands_ and outputs +the _functions_, _options_ and _option_ values, _operands_ and outputs described in the section [Default Registry](#default-registry) below. Implementations MAY implement additional _functions_ or additional _options_. @@ -271,7 +271,7 @@ which only expects the `accord` option: # Default Registry > [!IMPORTANT] -> That part of the specification is part of the Tech Preview +> This part of the specification is part of the Tech Preview > and is **_NORMATIVE_**. This section describes the functions which each implementation MUST provide