Create notes-2024-06-24.md

meetings/2024/notes-2024-06-24.md

@@ -0,0 +1,194 @@
+# 24 June 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Eemeli Aro - Mozilla (EAO)
+- Elango Cheran - Google (ECH)
+- Richard Gibson - OpenJSF (RGN)
+- Tim Chevalier - Igalia (TIM)
+- Staś Małolepszy - Google (STA)
+- Matt Radbourne - Bloomberg (MRR)
+
+Scribe: STA
+
+## Topic: Info Share
+
+APP: EAO and Mark Davis and Harmit and APP had a call about bidi design. Conclusion: APP will go back to the design and set up the isolation in a permissive way on the req level, and to require people to be strict about what they emit. Expect PRs from APP.
+
+ECH: Another reminder about the intro to bidi Unicode event tomorrow. It's free, it's a webinar. http://unicode.org/events/
+
+ECH: We're trying to meet up with people from the JS TG5 group and think about how we can collect user feedback. They're looking to set up a time. Here's the doodle:
+
+https://github.com/tc39/tg5/issues/3
+
+https://crab.fit/tg5-mf-feedback-planning-504960
+
+EAO: My understanding of what TG5 can help with: things we need to resolve to make progress and call the spec final. It's not about designing the questions and who and how to ask. For this task, they collaborate with someone from the U of San Diego.
+
+ECH: We don't know what the people will say.
+
+APP: If you're interested in participating, put your name in the doodle.
+
+ECH: We do know what we want to know. Is the wiki's task list the right list?
+
+APP: The task list is wider. There's a list with questions we want feedback on.
+
+ECH: Today I should be able to merge the ICU4J PR from MRR into the Conformance repo. https://github.com/unicode-org/conformance/pull/175. Seeing divergence between the impl and the spec test.  
+
+EAO: Can you clarify what the nature of the failures is?
+
+ECH: 80% of cases are errors, meaning the impl didn't complete due to parsing errors. And the remaining 20% are test failures. Many of these failures is due to a different fallback value returned from the implementation 
+
+TIM: Surprised by the results. ICU4J has its own copy of the spec tests. Some are skipped, but most are not modified and do pass. How can the results be so different?
+
+STA: for the purpose of the notes, 80% … some of these test failures are due to the fallback. Harness is not able to catch errors when we expect errors? 
+
+ECH: that’s not a problem yet. There are not a lot tests that are simple positive tests: here's a patterns; it should return this and that.
+
+MRR: I think it's something with the test execution rather than the test content.APP
+
+## Topic: Tech Preview
+
+Let’s review the Task List:
+
+https://github.com/unicode-org/message-format-wg/wiki/Things-That-Need-Doing
+
+APP: It would be good to have people sign up for things that need doing. Put your name on the wiki. I'm working on bidi. ECH is working on the error handling (not all the bullets on the list). 
+
+EAO: Am I listed for anything there? (APP: No) I'll take a look and put my name down.
+
+## Topic: PR Review
+
+### 806
+APP: Let's discuss resolved values first.
+
+TIM: I put this back in the draft mode. What's blocking: the test isn't fully fleshed out. It's meant to list the options that we're considering. In the meantime, it became pretty clear that we're taking the direction similar to #728. Didn't want to put the time to make everything very formal. It's useful to document the paths we didn't take, but not crucial right now.
+
+APP: Let's discuss resolved values.
+
+### 804
+APP: No approves, some feedback requests. I think we're fairly close to knowing what we want to do with error handling.
+
+ECH: I accepted the suggestions by APP and EAO this morning.
+
+EAO: I think we're well aligned: when a formatted message produces an error, you should be able to at least get an error code out of it.
+
+ECH: Last week, I was advocating for returning at least a bool. And EAO asked "can we not afford two bytes?"
+
+APP: Here's the current text:
+
+> A message formatter MUST signal errors required by this specification. It SHOULD provide the specific information for each error reported. A message formatter SHOULD provide a fallback representation of the message.
+
+APP: We can have stronger normative requirements. We can force implementors to always record the information on each error. Signaling errors and producing fallback are are separable requirements.
+
+EAO: I believe we reached a consensus that the bare minimum for signaling is a 2-byte error code. What we don't have agreement on is whether we have a MUST or a SHOULD wrt. providing a formatted fallback result. First, identify if this is indeed the one thing that we have left to agree on?
+
+ECH: I'm not entirely in agreement with the 2-byte error code. There could be multiple errors that occur. It feels weird that we'd tell implementations to pick only one. A bool works around this problem. We're making assumptions about the different environments and implementations.
+
+APP: The above may be overly specific. It's not about the size. Think about the Java implementation. If I throw a RuntimeException, it doesn't tell me the kind of the error. The question is whether we'd require to throw an enum exception type, or are you just allowed to say "error!". We want to be permissive enough to allow choices. It's not about the size b/c it might not be an integer at all.
+
+RGN: The reason to return more than a boolean is developer experience. "You did something wrong" – OK, what is it? We should require at least the indication of the type. Don't specify what exactly is emitted/thrown, but specific the type of error.
+
+EAO: In the alternative that I proposed earlier today:
+
+> An implementation MUST provide a way for a user to be informed of the name of at least one of the errors, either directly or via an identifying error code.
+> An implementation MUST provide a way for a message with one or more Resolution Errors or Message Function Errors to be formatted using a fallback representation.
+
+APP: I'm in violent agreement with ECH, EAO, RGN. I added the following requirement to the design:
+
+> As a software developer, I want calls to message format to signal runtime errors in a manner consistent with my programming language/environment. I would like error signals to include diagnostic information that allows me to debug errors.
+
+MRR: The snippet from EAO is probably the only safe thing that we can specify. Some implementations may produce different sets of errors depending on how they are evaluated (e.g. is this an error on line 1 or 2?):
+```
+.local $foo = {$bar}
+{Hello, {$bar}!}
+```
+
+APP: Are we in agreement about the first bullet above?
+
+ECH: Yes, I think it's OK.
+
+RGN: We expect a fair amount of creativity in how implementations may signal errors: throw an exception, return an int, return a compound value, return a boolean and instruct to call a separate API. We should include all of them in the spec as a non-normative illustration.
+
+APP: It can be boolean as long as there's an API to find out what the error was.
+
+APP: There are well defined fallbacks in the spec today. You could say there must be a means of obtaining a fallback string. Or must be a way to either get a formatted string or a fallback. The reason is: my model is number format in Java, one way to call it is to get as much as you can.
+
+APP: Do we require a method that always returns a string, and must never produce an error.
+
+EAO: It must be a MUST. (EAO has dropped)
+
+APP: Why is it not OK to produce errors?
+
+EAO: Composition of implementations. Example: server-side hydration. One impl server side, another on the client side. I need them format the same way, even if they're buggy. 
+
+APP: These are erroneous messages.
+
+STA: Remember from Mozilla days. formatToString method always returned a string. DTD localization. In case of a misformed entity, it would break the whole UI “yellow screen of death” because of how presented. Never allow this to happen again. Could always wrap in a try/catch. We struggled with startup performance. Just having that wrapper was hurting perf. Useful to have a method that always returns a string.
+
+APP: That's an implementation decision. We can recommend it, because it may be a good idea. The question is whether we mandate it.
+
+EAO: What are the ICU implementations going to do? Will they behavior be a MUST or a SHOULD? If it's a SHOULD, will icu4[cjx] provide these methods? If not, then it should be a MUST. If yes, I don't care that much.
+
+ECH: My sense of the discussion: ICU cannot fail. It always tries to provide something. It's kind of how ICU works in general. Cannot throw an exception. Fairly confident that ICU implementations will have fallback representations.
+
+APP: In Java … there's `format()` and `formatToString()`, and only one of them is allowed to blow up.
+
+RGN: This group has spent a lot of time defining fallback representations, quoting the best interest of end-users. I think it carries over to this discussion. It's acceptable to also have a fallible approach. It's not practical to build a fallback-aware solution based on the implementation that doesn't support it natively.
+
+TIM: I think this is entirely feasible in ICU. In order to support a version that always provides a fallback and one that can return an error, when we have `format` (format to parts) and `formatToString` (format to string), there will need to be 4 different APIs to support all those combinations. I’m not sure yet if that can be reduced down to only needing 3 different APIs.
+
+APP: Does anyone disagree with requiring that there be some way to get the fallback string. No disagreement. Final devil's advocate argument: will we discourage any implementers?
+
+EAO: Given how much customization we require, don’t think that’ll be the “last straw”.
+
+STA: response to something RGN said. Not practical to build something like that? Create building blocks and let callers decide what to do with them. Leaving some of the fallback to the caller. Spent a lot of time defining the fallbacks, so that makes sense to me.
+
+APP: Resolution: there must be some way of getting the fallback string. Let's proceed to make that a requirement.
+
+EAO: Would it be a matter of accepting my suggestion (two bullet points above)?
+
+APP: Some suggestions: (1) don't mention the name of the error.
+
+EAO: Optimize for users googling for the error code.
+
+APP: I agree. But it doesn't have to be by name. An E code would do.
+
+APP: (2) I'd bring all error types and define the fallback behavior for all of them, rather than single out just two kinds.
+
+APP: (3) Normative MAY is a permission to do something, and usually is a recommendation. Instead: you MAY use multiple methods to meet these requirements.
+
+EAO: (2) has impact on how cleanly we can separate the phases of parsing and evaluating. On (3), we could use a non-normative NOTE.
+
+APP: Two action items: We need to update the design. ECH, can you do it? (ECH: Yes) When we get a couple of ship-its, I'll merge it. Who would like to work on the implementation in the spec? (EAO: I can do it)
+
+APP: The currently proposed design should become an alternative. We also need edits to reflect the state of this discussion.
+
+APP: Once this is done, we'll treat error handling as accepted.
+
+EAO: One detail I'd like to highlight. Currently, we allow for custom functions to define their own fallback representations. Do we want to keep allowing this? It would end up meaning that individual formatting functions must signal upstream that they failed and what the fallback was.
+
+APP: The current idea is that we want to return the operand in curly brackets.
+
+EAO: The original idea with the custom fallbacking was to allow custom functions to decide that revealing more information that we mandate is safe.
+
+ECH: It may be a good idea to be more lenient with custom functions. They are still being called by the formatting engine. You could have a more permissive method. The use-case of hydration, we have it at Google as well. If you're a developer with this use-case, it's your responsibility to make sure that the two implementations cooperate, including the custom functions that you use in both of them.
+
+### 799
+
+APP: Don't see any new activity. There was a comment from ECH. Would you like to discuss it?
+
+ECH: If Tim's happy, I'm happy.
+
+TIM: I wouldn't say that I'm happy, but I'm not going to block this. Seems like there was no commentary.
+
+APP: I'll not merge it right now, but please take a look and when I get 2 shipits, I'll merge.
+
+
+## Topic: AOB?
+
+EAO: Are we doing the in-person meetup at TPAC?
+
+APP: Yes.
+
+(Discussion of formatToParts and the leopard behind the locked door)