Progress on a full spec draft

[eemeli]

In response to the CLDR-TC / ICU-TC request communicated last week by @nciric, @zbraniecki and I have been putting together a more complete sketch of what we think a full MessageFormat 2.0 spec might look like. It's available here:

https://github.com/unicode-org/message-format-wg/blob/ez-spec/spec.md

This is still a work in progress, but it's trying to provide a more holistic view to the whole spec, and how all the parts of it connect together. We're still working on it, but would very warmly welcome comments from the wider group. In particular, if you find that there are aspects that are missing or left unclear, we can work on including and improving those in particular.

The XLIFF 2 module and its transforms are not yet specified, but we are simultaneously working on a spec for the JavaScript Intl.MessageFormat implementation, as well as a DOM Localization spec on top of that; links to these are included in the spec's intro. The JS polyfill is currently lagging a bit from this proposed draft; it'll be updated to match shortly.

This spec text includes a number of aspects that have not yet been considered much by the WG, such as the proposed syntax, aliases, display/markup elements, and a couple of flavours of metadata. These are all topics that we ought to cover deeply, and to revise as necessary.

I've understood from @stasm that he'll also be presenting an alternative syntax proposal. We've tried to align our syntax sections to make them easier to compare against each other. There are still many parts of the syntax in particular that are fluid, such as the notation of message groups in the resource-level syntax.

This discussion is intended to collect comments on this specification draft.

[eemeli]

A (very) brief overview presentation on the proposal has been prepared for Monday's call.

[eemeli]

After some discussion with @zbraniecki, we've ended up dropping resource identifiers from the message references in the ez-spec proposal. This is in no small part based on last Monday's WG session on message references, and our subsequent sense that the use cases for references away from the current resource may also be served by other means.

With message references restricted to the current resource, a formatter instances may be naturally built around a single message resource, and the validity of its internal references ensured without external dependencies.

This does carry a need to ensure that creating and in particular memoizing message formatters is sufficiently cheap to allow for the use of custom functions to implement such external message references. This isn't necessarily simple. Regarding the Intl.MessageFormat ECMAScript proposal, it means that we may need to require using immutable records rather than objects when passing in message resources, to help ensure the immutability and memoizability of formatter instances.