Create notes-2024-08-19.md

meetings/2024/notes-2024-08-19.md

@@ -0,0 +1,272 @@
+# 19 August 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Eemeli Aro - Mozilla (EAO)
+- Mihai Niță - Google (MIH)
+- Elango Cheran - Google (ECH)
+- Richard Gibson - OpenJSF (RGN)
+
+Scribe: MIH, help from ECH
+
+## Topic: Info Share
+
+## Topic: Issue review
+https://github.com/unicode-org/message-format-wg/issues
+Currently we have 58 open (was 64 last time).
+15 are Preview-Feedback
+0 are resolve-candidate and proposed for close.
+0 are Agenda+ and proposed for discussion.
+0 are ballots
+
+
+
+### #859 [DESIGN] Number selection design refinements #859
+
+EAO : do you get my point about why I find problematic to take some of the options instead of all the options
+
+APP: I think we are all grappling with the same problems.
+As a message writer, if the UX asks me for certain values, how do I write them.
+For integers it is obvious, but decimals are problematic.
+Problems with different notations, scientific, etc.
+How do I select 1.2345 ?
+In code how does the string get into a number?
+There is no easy way out of that.
+
+EAO: I would say that fundamentally if we need a match for 1.2345 the dev would create a value from data outside MF2 that is testable.
+
+We should offer no support to make it easy in MF2 to do rounding in code, etc.
+
+MIH: I cannot find any good use case to provide `|1.00|` as a key in a `.match` statement. This existed in MF1 for a long time, and it does matching numbers, and nobody complained. Matching ` |$1.00|` is already handled by plural rules.
+
+APP: Yes, I semi-agree with that. The only case is when the exact match value also matches a plural category that is specified. Ex: if you have driving directions that say 
+
+
+Think “in half a mile” or situations like that.
+Maybe we should stick to our guns in regard to decimal matching.
+
+To EAO’s point about formatting outside, occasionally we need selections on non-numbers.
+
+MIH: NumberFormat does selection on fractionals. It’s not like it only works on integers. If you do numeric match on 0.5, it’s fine, it results in “in half a mile”. There’s not a case where you match on `0.5` to say “in half a mile”, but you say something different for 0.500.
+
+EAO: The “in half a mile” example sounds like choice format. You’re not looking for a specific value, but insead, a range of values.
+
+One can write a custom selection function.
+
+APP: time-box this.
+I will go back to the design doc and make some changes.
+To simplify the selection, to integer selection.
+
+We can discuss some more. But I think we can have a path forward.
+Without making this too complicated.
+
+EAO: Technically, what we have is not matching on integers. It’s matching on all numbers, but we haven’t defined how the matching is to be done.
+
+APP: Understood, I’ll revise the design 
+At least document better where the “sharp edges” are.
+
+ECH: Is there a way to solve this in the registry?
+If we need to do selection on decimal numbers?
+
+APP: exact match on decimal numbers, we can look at the serialization and match against serialization.
+If I give you a big decimal 1.00000001 + options, how do I know if this matches?
+
+ECH: ICU had to do this already, both in C++ and Java.
+
+MIH: I’m still debating whether it is good to match on a formatted number. I still think it is worth considering whether it is beneficial to have the keys as strings and then match as numbers.
+If the keys are numbers, and we compare numbers, it is a lot easier.
+
+EAO: Should we consider the options for number formatting. We have an example in ICU MessageFormat. You can offset for a plurals / ordinal selector. That option is not taken into account for exact matching, but it is taken into account for plural rule category matching.
+
+APP: I will rehash the design document?
+### #845 Accept attributes design & remove spec note #845
+
+APP Has merge conflicts.
+I think it only implements things that we already agred on.
+### #824: Select "Match on variables instead of expressions" for selection-declarations #824
+
+APP: EAO, you were not here. 
+I think we should go to ballot with this.
+You might want to go look at the notes
+
+EAO: can we narrow down the options to a smaller set?
+
+APP: personally I would like to see an emerging consensus.
+
+ECH: RGN, since you are here, how do you feel about this PR?
+Because I couldn't really quite tell.
+Also refers to the discussion in #736.
+
+ECH: we have a .match and we put the function in the selectors.
+Do we or do we not that the options we provide to the selectors are “sticky” to the arguments we are giving to the selection.
+
+RGN: people can have intuition in both directions.
+Existing tools can eliminate ambiguity with an extra declaration.
+
+APP: I hear that. Doing nothing is confusing, at least to me.
+I look at the message in the example, and it feels messed up.
+When we write date selections, we would want to get to the calendar.
+What can I do so that if I write an `.input` I don’t repeat myself again in `.match` 
+We can disallow any kind of expressions in the selector.
+
+EAO: as we discovered, when we look at the syntax of `.match` we don’t all agree that the expression there is modifying the argument or not.
+Do you agree that this is a problem, and we should not allow this confusion to arise?
+With the cost that when we select on an expression that does not show in formatting we still have to declare with an `.input` or `.local`.
+
+ECH: when you select on a person object, the selection might be on the gender of the person.
+But the formatting of the name depends on the whole `Person` object. Ex:
+
+```
+.match {$person :gender}
+male Bienvenido {$person :person}
+female Bienvenida {$person :person}
+other Bienvendos {$person :person}
+```
+
+I think we are conflating these operations.
+If someone needs to repeat, they have the option to declare, today.
+There is no need to force it on them.
+Legislating things adds friction.
+
+APP: when you select on numbers, you want to select on the same things as what you format.
+I can imagine selectors where you want a different selector than the formatter.
+That means “double annotation”. Some selectors might be better not-annotated.
+
+
+RGN: concision and simplicity are not the same thing.
+Extra verbosity is well worthy for extra clarity.
+I mean to require an explicit declaration.
+
+ECH: you don’t need to require it, but if you want to match selection and formatting, you need to declare.
+This is compatible with “do nothing”, I think.
+
+RGN: I am in favor to forbid the possibility of the formatting options used for selection be different from those used in formatting the pattern.
+
+APP: look carefully at the examples in the “leave as is”
+
+ECH: I understand the plural selection example very well, in which the formatting required for selection should be reused when formatting the input number for the message pattern. However, I gave you a case right above where the formatting for selection is not the same as the formatting for the message. That’s a counter example proving that we can’t say in all cases that selection “formatting” is the same as pattern formatting.
+
+Because it’s not universal in all cases, I can’t support the alternative based on an assumption that these concepts are connected in all cases. That alternative to “match on variables instead of expressions” is  legislating that formatting is done in a `.local` and referenced as a variable in `.match`, which is motivated by the idea that the formatting of the placeholder in the pattern will be the same as the selector, and that’s not always true.
+
+MIH: I would like to not changing the syntax, in which we support assignments in the `.match`. But we can make it a data model error as EAO suggested if there is a different function used in the selector vs. the function used in a placeholder of a pattern. If this is what EAO described, I would be fine with it.
+
+EAO: this alternative says that you need to annotate a selector.
+The new wording would be that if that when you use a variable in a selector, everywhere where you use that should be annotated.
+
+APP: let’s add that at the doc, read the doc afterwards.
+Let’s see if we can close in and decide what we do here.
+
+### #834 Update the stability policy #834
+
+EAO: what we promise (too much) is that a format will always format the same, forever.
+What I think we should promise is that it will format to something valid.
+
+APP: the output might change (because locale data changes).
+But the output will not “break”
+
+EAO: if it formats “fine” with v2.0 then it will format “fine” with v2.1
+
+APP: I was thinking “would not produce an error”
+I think you suggest something stronger.
+
+EAO: if an implementation changes nothing, only moves from v2.0 to v2.1 the result will still be formatted without error and without fallback, if v2.0 was without error and without fallback.
+“No error” is less than what I want.
+
+APP: I added some extra requirements.
+I am trying to make all of these promises, making them properly enumerated, rather than one portmanteau promise.
+
+EAO: I think I want that portmanteau promise.
+It would not want to go from a non-error to an error when we update.
+
+APP: a stability policy is a strait jacket we agree to put on ourselves.
+As opposed to things that we do outside of policy.
+I don’t want to overpromise, because that would prevent honest corrections.
+### #634 [DESIGN] registry maintenance #634
+
+EAO: …
+
+APP: this PR is a design doc, on how to manage the registries.
+I’m open to suggestions.
+But we are starting to play with the registries.
+How will we work with these?
+This is a swipe at that.
+I would like to submit as proposed, so that we can make it easier to read it.
+And open to update afterward.
+
+EAO: I’m entirely on board describing functions and options one is allowed (not not required) to implement.
+“If you do this, do it this way”
+
+I’m on board with `u:` for the “global” options described.
+What would a `u:` function do? Why would it exist? Why put it in the `u;` space and not in the standard one?
+
+APP: I didn’t want to say “we will never put a function in the `u:` namespace..
+We already have functions for testing (for conformance) that might live in the `u:` space.
+
+EAO: is “registry” the right word to use for these things?
+Should we be calling them default functions?
+Sounds as if we can choose between registries?
+
+APP: everyone is required to have the default one.
+And there can be extras, at all kind of levels (proposed, company, application)
+We’ve been using “registry” for years now.
+
+MIH: You touched on the fact that IANA might want to use that. If we don’t like “default”, then we can call it “standard” to say that you cannot take out things from it or change it. The word “registry” does not bother me that much.
+
+EAO: in our communication we often talked about “the registry”
+Maybe we should not use “registry” when we talks about the standard functions.
+And I think that “RGI” is too clunky.
+
+APP: specifications, what forms “the registry”.
+It is not machine readable. It used to be, but we took it away.
+It is the same as when you registry various URI prefixes. You write a spec.
+And have a status, maybe a namespace.
+So it is a collection of specs.
+That might be a way to thing about it.
+The RGI was intentionally “clunky”
+
+EAO: built-in functions sounds like a name that is user friendly.
+“Registry” is an implementation detail.
+
+MIH: The registry is growing over time. Also, all functions are on an equal footing: functions that are in the standard registry are no more special than functions that are in private registries. That is why I prefer calling them the same thing.
+
+APP: maybe we can talk about “registration process”
+With “recommended addons” or something like that.
+Might not be a registry file that one can download.
+
+ECH: are we bikeshedding the name?
+
+APP: yes
+
+ECH: I am not “wedded” to the word “registry”
+I’m cool with “registration process”, but consistency (standard functions, company functions, custom functions)
+
+EAO: need to talk about how the registries will be versioned.
+Is there a way to implement an updated version of the registered functions.
+
+ECH: a hassle to deal with different versions of various parts.
+
+MIH: the main reason we separated the spec proper from the registry was to be able to add functions without changing the spec.
+Changing the spec version sounds scary.
+Will all my tooling break (if the spec changed), when all we did was add an option to a function?
+We can maybe version “the whole registry”, separate from the MF2 spec proper (syntax, data model, etc)
+
+APP: I think the function registries can be LDML versioned, and my expectation is that we might change in time. We can try to stabilize, as each implementation is required to implement those functions.
+We can use the “twice per year” LDML version.
+Gives us some kind of predictability.
+
+EAO: biannual tied to LDML sounds like a good idea.
+But for a user reading the spec, I am interested in options not required, but recommended.
+Wouldn't  it be more readable if they were in the same document?
+For example if I want to implement the `:number` function I have to read 3 documents.
+Isn’t that clunky?
+
+APP: OK
+
+I was thinking RGI as a bucket for “this is done, but not required”
+
+MIH: Can we do something like what ICU does for public APIs, where we tag them with statuses “draft”, “technical preview”, “beta”, “final”?
+
+APP: the things in the `u:` namespace live in a different place than the main registry.
+So it needs rules for that too.
+
+