Discussion Issue for the Approval Ballot

[aphillips]

This issue is for the discussion of the Working Group Ballot of the MF2.0 approval found in #955

• This is the place to explain your "Approve" or "Disapprove" vote.
• File individual issues for technical problems, editorial issues (such as spelling), or other topics orthogonal to whether we should approve the specification.

[eemeli]

For those of you playing along at home, the latest prerelease version of the JS messageformat library implements the current version of the spec, including everything except for :unit.

npm install --save-exact messageformat@next

import { MessageFormat } from 'messageformat'

const msg = new MessageFormat('en', '{$cost :currency u:locale=fi}');
const cost = { valueOf: () => 42, options: { currency: 'EUR' } };
msg.format({ cost });  // '42,00 €'

msg.format({ cost: 42 });  // '{$cost}'
// Warning: A currency code is required for :currency

msg.formatToParts({ cost });  // see below

[
  {
    type: 'number',
    source: '$cost',
    dir: 'ltr',
    locale: 'fi',
    parts: [
      { type: 'integer', value: '42' },
      { type: 'decimal', value: ',' },
      { type: 'fraction', value: '00' },
      { type: 'literal', value: ' ' },
      { type: 'currency', value: '€' }
    ]
  }
]

[gibson042]

FWIW, I'm still not a fan of that deep structure, and much prefer a flattened representation as in the existing Intl APIs such as DateTimeFormat.prototype.formatRangeToParts.

const dtf = new Intl.DateTimeFormat("en-US", { year: "numeric", month: "short" });
dtf.formatRangeToParts(new Date("1900-01-02"), new Date("1999-12-30"));

[
  { type: 'month', value: 'Jan', source: 'startRange' },
  { type: 'literal', value: ' ', source: 'startRange' },
  { type: 'year', value: '1900', source: 'startRange' },
  { type: 'literal', value: ' – ', source: 'shared' },
  { type: 'month', value: 'Dec', source: 'endRange' },
  { type: 'literal', value: ' ', source: 'endRange' },
  { type: 'year', value: '1999', source: 'endRange' }
]

[sffc]

FWIW, I'm still not a fan of that deep structure, and much prefer a flattened representation as in the existing Intl APIs such as DateTimeFormat.prototype.formatRangeToParts.

I agree with this, but it does not have to do with MessageFormat 2.0, right? That has to do with Intl.MessageFormat. I don't see where in MessageFormat 2.0 it defines formatToParts.

[gibson042]

Right, and I see that I misunderstood the sample anyway. Marking off-topic.

[sffc]

I have a question about the file "registry.md"

It says:

This section defines the REQUIRED functions which are REQUIRED for conformance with this specification, along with RECOMMENDED functions that SHOULD be implemented to support additional functionality.

However, I do not see a list of which functions are required and which are recommended.

I also submitted concerns about certain functions in registry.md:

• [FEEDBACK] Please move style percent to its own function #956
• [FEEDBACK] The :math function should be better-specified #959
• [FEEDBACK] Limits of Digit Size Options #960
• [FEEDBACK] Be more specific about time zone IDs #962
• [FEEDBACK] Don't include a time zone option, or be strict if you do #961
• [FEEDBACK] Resolution between input calendar and message calendar #963

And there is still the section entitled "Field Options". I have been under the impression since early in the year that these would be implementation-specific options but not in the main registry. Their status in registry.md is unclear.

In any case, I was told that concerns involving registry.md do NOT impact readiness for 46.1, so this does not impact a "vote". If these are things that cannot be easily changed after 46.1, however, I would be quite concerned.

[aphillips]

@sffc: Thanks for your comments and careful read-through.

I have a question about the file "registry.md"

All of the functions currently in registry.md are REQUIRED. There is one RECOMMENDED function being considered (it is :unit). See #922 for what that currently looks like.

And there is still the section entitled "Field Options". I have been under the impression since early in the year that these would be implementation-specific options but not in the main registry. Their status in registry.md is unclear.

These are not implementation-specific options. They are required on :datetime (they do not exist on :date or :time) and cannot be used in combination with style options. I know you have an interest in our replacing these "option bag" style options with semantic skeletons at a later date. That can be done by future additions to the registry, possibly accompanied by deprecation of these options.

The registry is separate in some ways from the rest of the message format specification, but we normatively require the REQUIRED functions in it. MF2 is not very useful without functions, so they were an important part of our deliverables. We have normative language around the functions and their options. We also have a stability policy that will come into effect in 47 (not 46.1), but which we really want to try to live by starting with 46.1. This policy makes promises about what can be changed in the function sets/registry.

[aphillips]

Balloting having been completed, closing this issue