Skip to content

Address #683: make registry data model non-TP #684

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Feb 23, 2024
Merged

Address #683: make registry data model non-TP #684

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
56f39a0
Address #683: make registry data model non-TP
aphillips Feb 22, 2024
ac4bbbc
Apply suggestions from code review
aphillips Feb 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 22 additions & 6 deletions spec/registry.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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_, _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_,
Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -258,6 +270,10 @@ which only expects the `accord` option:

# Default Registry

> [!IMPORTANT]
> This 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.

Expand Down