[DESIGN] Maintaining the Standard, Optional and Unicode Namespace Function Sets

[aphillips]

Capture for discussion the general ideas for how to organize the registry in the post-45 time period.

Notably, @sffc mentioned number skeletons in a comment on #621:

Note: My original idea from 5 years ago was that MF would use number skeletons and then become the specification that defines number skeletons since they are currently specified only in the ICU documentation.

This goaded me to write down some of the concepts floating around in my head about how to manage the registry going forwards.

[macchiati]

I like the direction. There are a few sections that remain to be filled out (eg What properties does the solution have to manifest to enable the use-cases above?
). Approving, assuming you want to go ahead with this, and flesh out more later.

[sffc]

Thought: should these "RGI" functions be prefixed in some way, like a vendor prefix, draft prefix, etc? For example, the definition of :person might need to change over time as more environments adopt it. Perhaps it should start as :person:draft or :person:2024a or something like that, only being promoted to :person once the design is finalized.

[aphillips]

RGI functions could be prefixed, but I think they are meant to pollute the common function namespace. We have :u namespace reserved below. The natural order of progression would be:

• :u:person <= early days proposal, leads to:
• :person "RGI" <= implement this if you wish to, leads eventually (maybe) to:
• :person <= implement this if you want to claim you support MF2

[eemeli]

This should also include options, so that e.g. :number skeleton could be specified, but would not be required.

[aphillips]

This was my intention. I'll add text.

[eemeli]

This seems like a definite improvement; see line comments below. On a meta level, I'd appreciate more explicit communication about the status of this long-running PR, especially as it's being deeply refactored like this. I can't tell if this is truly ready for review, or if it'll still be iterated on before further consideration.

[eemeli]

This phrase seems to be missing some words.

[eemeli]

We really should finally align on how to speak about resolved values, because that's clearly relevant here as well. Note also that formatting function and selector function are not terms that we've defined so far, and I don't think that they should be.

[eemeli]

Are these terms used by CLDR or ICU already, or are we inventing something new for MF2? My own preference would be to use instead something like alpha/beta/[no tag]/deprecated, which probably are better understood by a layperson.

I also can't figure out what the difference between "Accepted" and "Released" might be.

[aphillips]

"Accepted" is a specification that has been reviewed and will be part of the next LDML release (but it not part of the current one).

These terms are similar to those used by the UTC, but there's no real attempt to be rigorous about them. The names are provisional and I'm open to suggestions. alpha/beta would be okay, once proposals are accepted, but you only have to look at emoji or language subtags to see that a lot of proposals get proposed that would never reach alpha.

[echeran]

Here's what I dug up about status labels for ICU/CLDR/Unicode

ICU:

• ICU API statuses - draft, stable, deprecated, obsolete (and discouraged in Java only?)
• technology preview is not defined, but has been used for a very long time (example from ICU v4.4). It is like draft, and draft is more or less like beta, but draft additionally signals to the user that there is no guarantee of stability, while draft means that the design iteration seems done so there probably won't be major changes.

CLDR: the processes have different labels depending on what it is. Data fields have statuses like unconfirmed. But for releases of CLDR, you have alpha, beta, and the unqualified final release itself.

Unicode data: at https://www.unicode.org/Public/, you have a draft subfolder that acts like the main trunk. Each versioned release has alpha, then beta, then the final release.

[eemeli]

Given that the u: space is stable, doesn't this mean that anything "incubated" there would need to remain there even after its "promotion"? And given that we are also proposing a process for introducing new items directly in the root namespace, why/what would we want to incubate in such a manner? I'd prefer this to be left out.

[aphillips]

Given that the u: space is stable, doesn't this mean that anything "incubated" there would need to remain there even after its "promotion"?

Yes. I think I say that somewhere?

And given that we are also proposing a process for introducing new items directly in the root namespace, why/what would we want to incubate in such a manner? I'd prefer this to be left out.

This is permission to promote something from u: to standard, sort of like the way browsers use prefixes in CSS. This might be a bad idea.

[eemeli]

The list of levels below doesn't match the lists above, which don't include Rejected at all and only include Proposed and Accepted for Optional items.

[macchiati]

In CLDR, we introduced the term 'technology preview' in CLDR 24 (2013), with a meaning corresponding to ICU's, except applied to XML structure & spec, instead of APIs. That is a status of a portion of the spec and/or data *within* a release. For the data, we have 4 statuses, as Elango said, but those aren't relevant.

…

On Tue, Aug 27, 2024 at 2:28 PM Elango Cheran ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In exploration/maintaining-registry.md <#634 (comment)> : > +The maturity levels are: +- **Proposed** +- **Accepted** +- **Released** +- **Deprecated** Here's what I dug up about status labels for ICU/CLDR/Unicode ICU: - ICU API statuses <https://unicode-org.github.io/icu/userguide/icu/design.html#icu-api-compatibility> - draft, stable, deprecated, obsolete (and discouraged in Java only?) - technology preview is not defined, but has been used for a very long time (example from ICU v4.4 <https://unicode-org.github.io/icu/userguide/strings/utf-8.html#abstract-text-apis>). It is like draft, and draft is more or less like beta, but draft additionally signals to the user that there is no guarantee of stability, while draft means that the design iteration seems done so there probably won't be major changes. CLDR: the processes <https://cldr.unicode.org/index/process> have different labels depending on what it is. Data fields have statuses like unconfirmed. But for releases of CLDR, you have alpha, beta, and the unqualified final release itself. Unicode data: at https://www.unicode.org/Public/, you have a draft subfolder that acts like the main trunk. Each versioned release has alpha, then beta, then the final release. — Reply to this email directly, view it on GitHub <#634 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMBHCM5DVSYJJMBPYGTZTTVO3AVCNFSM6AAAAABDE4ARSCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDENRUGQ4TMNJXGU> . You are receiving this because you were assigned.Message ID: ***@***.***>