Create notes-2024-04-22.md

unicode-org · Apr 22, 2024 · 4c5e301 · 4c5e301
1 parent 0e1304b
commit 4c5e301
Showing 1 changed file with 296 additions and 0 deletions.
diff --git a/meetings/2024/notes-2024-04-22.md b/meetings/2024/notes-2024-04-22.md
@@ -0,0 +1,296 @@
+# 22 April 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Eemeli Aro - Mozilla (EAO)
+- Mihai Niță - Google (MIH)
+- Elango Cheran - Google (ECH)
+- Matt Radbourne - Bloomberg (MRR)
+- Richard Gibson - OpenJSF (RGN)
+- Tim Chevalier - Igalia (TIM)
+
+**Scribe:** MRR
+
+## Topic: Tech Preview
+
+LDML45-Tech-Preview branch and release created
+Blog post should go up in a couple of days
+
+
+## Topic: PR Review
+Timeboxed review of items ready for merge.
+
+|  PR  |                      Description                     |              Recommendation             |
+|:----:|:----------------------------------------------------:|:---------------------------------------:|
+| #772 | Add use case for `source` expression attribute       | Merge                                   |
+| #771 | Remove inappropriate normative statement from errors | Merge                                   |
+| #770 | Fix options in examples to match default registry    | Merge                                   |
+| #769 | Add test:number and test:plural function definitions | Discuss                                 |
+| #767 | Add new test schema                                  | Discuss                                 |
+| #755 | [DESIGN] Effect of selectors on placeholders         | Discuss                                 |
+| #753 | Add design doc on function composition               | LDML46                                  |
+| #744 | Fix design doc                                       | Merge (approved, waiting on bearfriend) |
+| #743 | Collapse all escape sequence rules into one          | LDML46                                  |
+| #728 | Add "resolved values" section to formatting          | LDML46                                  |
+| #704 | Address #703: make syntax/data model fallback clear  | LDML46                                  |
+| #673 | Fix whitespace conformance to match UAX31            | LDML46                                  |
+| #646 | Update spec as if PR #645 were accepted              | LDML46                                  |
+| #645 | Add design doc for dataflow for composability        | LDML46                                  |
+| #634 | Design doc to capture registry maintenance           | LDML46                                  |
+| #584 | Add new terms to glossary                            | LDML46                                  |
+| #558 | Add <when> to help select the right <match>          | LDML46                                  |
+| #558 | Add <when> to help select the right <match>          | LDML46                                  |
+
+### #772
+APP: Any objection of merge? [No objection]
+
+### #771
+APP: Effectively a typo fix. Any objection to merge? [No objection]
+
+### #770
+APP: Similar to #771 - More fixing of options.
+
+### #769
+APP: One question would be whether we want to use our reserved namespace for this `:u`
+
+EAO: As I understand, U namespace means it will end up real. Putting test functions here could be bad. Using a `test` namespace would be implicitly what it’s for. This function means we don’t need to depend on any implementation bodies.
+
+APP: Presumably, if you want to test your impt, you’d have to add these functions.
+
+EAO: 1 function with 3 different modes.
+
+APP: I was a pedant about the form this would take.
+
+ECH: It’s interesting. The only valid inputs are 0 and 1?
+
+EAO: The operand can be anything numeric.
+
+ECH: FD is decimal?
+
+EAO: Fraction digits became `FD`
+
+MIH: I like the idea. I’d like to nitpick the results. E.g. what about numbers that end in 1?
+
+EAO: That’s included. Check “FD=1”. Look for “1.0”.
+
+APP: Why don’t we leave it open and mull it over. If it’s unclear, we can add documentation. If we modify the tests to use this instead of e.g. `:number`, we want to ensure that it meets all the requirements.
+
+### #767
+MIH: Doesn’t play nicely with lots of parsing libraries.
+
+EAO: JavaScript + TypeScript + Python are fine. If we need to get rid of this, we should drop the array of strings approach.
+
+MIH: I’m not saying it’s not doable. You get some funny JSON object - you have to say “if it’s an array, do one thing. If it’s a string do another”
+
+MRR: I think this logic is needed in both cases.
+
+EAO: No further comment.
+
+APP: People’s authoring experience of messages is a string. If we’re not happy about that, it’s indicative of how people will feel using MF2. We need to feel the pain of that. We should be careful in inventing things.
+
+MIH: It tells us about the storage format, which is JSON. A lot of existing formats have a way to wrap strings. We didn’t introduce that pain.
+
+EAO: We’ve made affordances in the syntax to accommodate container formats like JSON (e.g. weird quote delimiters). If these are insufficient, we should reconsider if these affordances make sense. All of this is beyond the scope of the PR. I’d be happier to just allow string values. Through practical experience, we can see if we need anything more.
+
+MIH: Don’t consider it a blocker.
+
+EAO: A recent addition from MRR is an addition/change of a set of error codes, which are different and richer than what we have before. It’s baked into the proposal. It effectively forms the base of common error codes across implementations.
+
+APP: This is something we’ve identified we need to do.
+
+MRR: It’ll be ready for another review in ~24h
+
+
+### #755
+EAO: It’s about a mismatch about what a selector is saying and what a placeholder is saying.
+
+APP: Or having a shorthand.
+
+### #753
+TIM: I’d like more comments, unless people don’t have anything more to add.
+
+APP: Do people want it published before we comment on it further?
+
+EAO: I’d like to do another review pass. I can do that in the next few days.
+
+### #744
+APP: I will chase our friend so we can merge that.
+
+### #743
+APP: EAO cleaned this up last week so it’s mergeable.
+
+EAO: So do we want this change or not?
+
+MIH: I’m not happy with it. The ‘reserved’ thing is the problem. We are damaging something to save something bad, in my opinion. My thinking is to mess with that, and not this.
+
+APP: I’m less worried about escape stuff unless it’s hard to parse. This simplifies things by removing escapes for ‘reserve body part(?)’
+
+MIH: I’d rather fix the escape.
+
+APP: Are there other opinions? The current system is very minimalist. This would allow people to escape {  }  |
+
+EAO: Currently, if you’re moving content from a pattern to a literal, you need to potentially change the escapes you use, because we allow for { } to be escaped in the pattern and nothing else [and vice-versa]. This is not adding new requirements for escaping.
+
+MIH: That makes me very much against it. If you sometimes escape it and sometimes you don’t.
+
+APP: I hear the argument about copying texti into a literal and suddenly having to modify it. Is that more important than not having 2 ways to have a string?
+
+ECH: It doesn’t seem like this change is changing a whole lot about what’s expressable, more just a cleanup of our syntax rules.
+
+APP: Not true- it permits some escapes that were not previously permitted. It changes the meaning of:  {{ \|  }}
+This would change the meaning of that to be a pipe with just some spaces.
+
+ECH: To me, this makes it easier to grok - I’ve seen backslash as an escape sequence. I think there’s an issue that MIH is pulling on that’s not going to address - the way that you represent certain features in the reserved area is difficult and inconsistent with other parts of the message.
+
+MIH: If we try to unify escaping rules, they should always be required (e.g. `|` in plain text and `\|` in a literal.
+
+EAO: It’s an error according to the spec.
+
+RGN: In every context?
+
+MIH: Yes
+
+RGN: That’s behaviour that we want. It’s better to have backslash only used for this purpose.
+
+EAO: The only reasonable non-error parsing of APP’s post is “space pipe space”. There is no chance that anyone would reasonably expect a \| to be anything other than an escaped pipe. The set of allowed escapes would be the same everywhere.
+
+MIH: “must be escaped” > “can be escaped”. If we include all these escape rules, they should be required everywhere.
+
+EAO: | would require escaping in a basic message?
+
+MIH: If we go this direction, I’d like the rules to be the same everywhere. My preferred solution is to fix the reserved thing.
+
+EAO: MIH, would you be willing to put forward a PR so we have this visible and written down?
+
+MIH: OK.
+
+APP: EAO, the thing you suggested - [content char to remove pipe?]
+If we require pipe to always be escaped, we have to remove pipe everywhere.
+
+EAO: If we are calling into question escaping more things in simple pattern, there are so many things we need to call into question - let’s not.
+
+APP: It’s not ready to merge, but close if we can agree on the escaping rules. Anything else on this? [No]
+I propose we skip the remaining PRs for time reasons
+
+
+## Topic: Issue review
+
+https://github.com/unicode-org/message-format-wg/issues
+- Currently we have 56 open (was 56 last time).
+- 14 are Preview-Feedback
+- 0 are resolve-candidate and proposed for close.
+- 1 is Agenda+ and proposed for discussion.
+
+| Issue | Description | Recommendation |
+|---|---|---|
+| #738 | Is it an error to pass a bad option to a function? | Discuss |
+
+### #738
+APP: Don’t have an error defined in errors.md, but it’s possible to pass a bad option. It’s obviously some kind of error. Is it permissible for a function to ignore it?
+
+EAO: It must be possible for a function to error (e.g. operands, selection, formatting). I don’t think in general we should be explicit about which we’re expecting. For built-ins we can be more specific about some. E.g. in a JavaScript context, errors are discover when Intl.number is called with an options bag. It’s not clear if this should be a resolution error or a formatting error. It’s likely that you’d use `:number` as a selector so you wouldn’t need an Intl.number for this. A lazy JS implementation wouldn’t need to know if it resolves to an error. It’s possible that our spec would need to know. I don’t think we should be strict on what we mandate here.
+
+MIH: I’m fine for functions to report errors. I don’t think we should require functions to report errors. E.g. functions that return a result string, but also report an error. Both ICU4C/J can’t do that. If the spec says you MUST report an error, it throws exceptions in Java. In Android, it may mean another play store review, or a watch firmware update.
+  TLDR on my take:
+  + to report an error
+  + to add some error type 
+  -  to make reporting error mandatory
+
+APP: Agree with EAO - it should be permitted that a function throws an error. One of those situations - an option was bad. We don’t currently have an error (bad operand). I think that’s fair. If you look at the built-in functions, we say what the valid names/values are and permit implementations to do other things, but not what happens if you pass a bad value. We should say something, even if it’s just so an implementation to choose what to do. As we allow new functions to be proposed. We should be clear whether an implementation can ignore a bad option. (e.g. if you misspell minimumFractionDigits, do you want it to throw an error or format everything as an integer?)
+
+EAO: It’s possible for us to require a resolution error for some bad options, but we are still allowing an implementation to only emit that error when it’s doing the formatting for the placeholder.
+
+APP: We haven’t done anything explicitly with bad options. Implicitly, you could say its an ‘invalid expression’.
+
+EAO: In no place do we say that the list of resolution errors is exclusive
+
+APP: Or the other kind. Selection errors are the in the province of the format[?] itself. Maybe #1 do we need a set of errors about bad option/bad option value? Or do we say implementation defined errors?
+
+EAO: MRR’s PR includes a list of errors. There is no way for the spec to generate those errors but we can make it so that the implementation can be emitted.
+
+APP: If we create the errors then people can emit them. We have to go back to the default registry and say if it’s implementation-defined. There should be any tests around this because there’s no rules around this.
+
+EAO: So let’s add this and we’re a step closer to being final.
+
+APP: Do we want to require that these are emitted, or make it part of the default registry.
+
+EAO: There may be places within the defs for the standard core functions for this.
+
+MIH: My implementation (ICU4J) ignores unknown options.
+
+APP: Bad value?
+
+MIH: I think I’m ignoring it - I’m fine to make it an error
+
+APP: e.g. `maxFractionDigits=foo`
+
+MIH: We have to think about when we add a formatter a year for now?
+
+TIM: My impl (ICU4C) ignores options with unknown names. There’s no errors about either one.
+
+EAO: For JS, we feed into Intl - for ‘foo’ it’s either type error or range error.
+
+TIM: Does that currently apply?
+
+APP: Not currently, but we should behave carefully. We’re not going to take any options away. We might add new ones - the stability policy allows. We want to be careful of a working message to stop working.
+
+EAO: I think we should make it explicit in number/datetime/etc, that unrecognized options are ignored, but using them is undefined behavior.
+
+APP: At the function level in the default registry or in the core spec?
+
+EAO: I think functions in the core registry - it applies to all of them.
+
+APP: OK - ‘unknown options are ignored’. Would that permit a function to throw an error for a non-default registry function.
+
+EAO: Not one of ours - anything goes. We want to have the freedom to add new options later. For an implementation to now ignore an option, that could emit an error.
+
+**_Action point for EAO - Craft the wording for this._**
+
+APP: We need to do the task of crafting the official error codes. I think the specific error IDs should go in ‘errors.md’
+
+TIM: The issue for tracking this is #706.
+
+EAO: I think we should rename the invalid expression error. With the syntax, we are using wording around ‘well meaning’ and ‘valid’. “Bad” is good.
+
+**_Action point for MRR - Add the error codes to errors.md_**
+
+EAO: Operand mismatch error is a bad operand error.
+
+EAO: Can we rename operand mismatch to “bad”?
+
+TIM: Is there an adjective that makes it clear that there’s a set of errors that come from a function, rather than MF2 as a whole?
+
+APP: There’s a class of invalid expression where maybe a function does not resolve properly?
+
+EAO: What do you mean?
+
+APP: [References errors.md] “Produces an error during function resolution”.
+
+APP: Should we move it out of resolution errors?
+
+TIM: I like the idea of defining a new class of errors - when writing an implementation I know what set of errors I can use.
+
+APP: Refactor bad expression, selection errors and formatting errors as ‘function errors’? That makes a lot of sense.
+
+EAO: “Message function errors” - We want the word ‘message’ in there - it’s going to get included in class names and so on - reported in logging etc. Message function error has a lot more context on where this has come from.
+
+EAO: [Proposes error types] Syntax errors / data model errors / resolution / message function
+[Proposed Message function sub-errors]: bad expression / bad operand / bad option / selection error / formatting error.
+
+APP: Previously bad-operand was a subtype of bad-expression - setting up to call the function
+
+EAO: I’d leave bad-expression as-is and not add more hierarchy.
+
+APP: bad-expression would therefore be any other errors
+
+EAO: Maybe there’s a case for operand/option-basket mismatch.
+
+EAO: What registry fuctinons are allowed to do is a separate PR.
+Refactor errors
+Clarify default registry functions can be added to later
+
+# Topic: AOB?
+
+EAO working on Python tooling - taking existing localization files and transforming to MF2 syntax and back. Useful for Mozilla - others might find it of interest.
+
+TIM working on a blog post about Igalia’s work on MF2. Will share a draft on Slack. Scheduled to come out after Addison’s post.