Add notes for 2024-04-29 (#777)

* Create notes-2024-04-29.md

* Update meetings/2024/notes-2024-04-29.md

---------

Co-authored-by: Addison Phillips <[email protected]>

Author: eemeli

meetings/2024/notes-2024-04-29.md

@@ -0,0 +1,136 @@
+# 29 April 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+
+- Eemeli Aro - Mozilla (EAO) - acting chair
+- Elango Cheran - Google (ECH)
+- Matt Radbourne - Bloomberg (MRR)
+- Mihai Niță - Google (MIH)
+- Richard Gibson - OpenJSF (RGN)
+- Simon Clark - Oracle (SCA)
+- Tim Chevalier - Igalia (TIM)
+- Ujjwal Sharma - Igalia (USA)
+
+Scribe: ECH
+
+## Topic: PR Review
+
+### #776 - Avoid presumptive use of ‘always’
+
+Merged.
+
+### #775 - Define missing definitions for ‘variables’
+
+TIM: I’m still waiting for APP to respond. He mentioned something at the end of his comment but hasn’t followed up.
+
+### #774 - Refactor errors, adding section for Message Function Errors
+
+EAO: Do you want to get rid of formatting and selection errors? 
+
+RGN: That’s just one possibility. If we’re going to keep them, further clarification is warranted. It’s not a clean category because there’s overlap. There would be redundancy in a traditional hierarchy.
+
+EAO: I’ll need to take a further look.
+
+### #773 - Add note about updates adding options causing errors
+
+Merged.
+
+### #769 - Add test:number and test:plural function definitions
+
+MIH: I would bikeshed on the the names. Instead of function, I would say selector. Also, we haven’t reserved the namespace segment test, which allows users to step on it.
+
+### #767 - Add new test schema
+
+Merged.
+
+### #755 - Effect of selectors on placeholders
+
+MIH: How do we allow for functions that change the type? For example, a function that takes a name and gives the date of birth? How do local variables interact? Even though it’s not directly about selection.
+
+EAO: That sounds like a separate matter. For complex declaration, and then you have a selector with further information in options, which references the same variable argument as the declaration. A solution of this design document will interact with the issues that you are describing.
+
+MIH: I think it’s important to address things that are tightly related in the same document. My first reaction is that you cannot touch this topic without addressing those other concerns.
+
+EAO: Maybe you are describing the separate discussion of “how do we define what a value resolves to?” If there is a separate topic, even if it relates to this, then file an issue, and we can discuss them separately.
+
+### #753 - Add design doc on function composition
+
+TIM: It’s been a while since I’ve looked at it. As a reminder, this isn’t to propose a solution but to give background. I have a separate PR to propose a solution. This is just laying out background, so I don’t know what more to do.
+
+EAO: Maybe you would be interested in reviewing this, MIH? I would like to take another look. So let’s keep this in the queue.
+
+## Topic: Issue/Design Doc review
+
+### Expression Attributes
+
+EAO: Is anyone interested in discussing this? STA is still not convinced that we need this feature.
+
+ECH: I would be interested in hearing that discussion. We have had discussions last week adding a use case for `source`.
+
+EAO: We currently don’t have a mechanism for attaching metadata to a placeholder.
+
+MIH: The way I see this is, why do we need this? They are options, like anything else. The only justification is that these can live outside a function. Isn’t that the only difference between this and options?
+
+EAO: In terms of syntax, yes.
+
+MIH: And what about in terms of functionality?
+
+EAO: The way I would differentiate them is that attributes impact the formatting context.
+
+ECH: I’m still not convinced that this is the only way to solve the problem. For example, you can make the function annotation of a placeholder optional. If it’s not specified, then the options serve as metadata for that placeholder.
+
+EAO: We could make attributes as things that never have runtime impact. Maybe we need to reserve attributes as special namespaced options so that they don’t interfere with other options, like `u:locale` or something. Would that make them more or less interesting?
+
+ECH: Are you talking about namespacing options? If so, that makes them more concerning and thus, much less interesting. Namespacing options would add a lot of complexity, and I still don’t see that they’re necessary.
+
+EAO: Namespaced options would allow implementations to provide built-in parsers for their values, rather than requiring each function author to roll their own.
+
+TIM: Can we make a decision on duplicate attributes, even if we don’t agree on attributes?
+
+EAO: I think it’s premature because we don’t yet agree that attributes should exist as a construct, even though we agree that there should not be duplicate attributes. Once we decide weather attributes should exist or not, then we can make a decision on excluding duplicate attributes.
+
+### #738 - Is it an error to pass a bad option to a function?
+
+MIH: I’m generally reluctant to have runtime errors unless they’re essential to have. With HTML, if you have junk, your page doesn’t explode – it still renders. It is not useful to give an error that isn’t actionable by the user. This does comport with how ICU does things in my ICU4J implementation.
+
+EAO: Are you saying that the ICU mandates that a fallback returns
+
+MIH: I defer to the ICU-TC. I’m just describing the situation in ICU.
+
+EAO: The spec text on formatting says that 
+
+TIM: It’s true that ICU can only concurrently return one error. I want to know where we require 
+
+MIH: It’s not just that. In ICU, if you return a value, then you ignore the error, and vice versa. You don’t return an error and a value at the same time.
+
+TIM: You’re correct. And I realize that I rely on that behavior in my ICU4C implementation.
+
+MIH: And ICU4C doesn’t represent errors in the same way as ICU4J.
+
+TIM: The more I think about it, the more I think that we need to design a separate mechanism to represent multiple errors. We would need to create a design proposal to the ICU-TC.
+
+MIH: Right, because that would be designing an entirely different mechanism than what exists in ICU.
+
+EAO: Is the resolution that we need in the spec text?
+
+MIH: Yes, because the spec is written in a way that forces unnatural things to different programming languages.
+
+TIM: MIH, do you mean unnatural as requiring multiple things to be returned by a programming language?
+
+MIH: Yes. Requiring things that are very difficult or impossible to represent in some programming languages and not others is not nice to have in spec text.
+
+EAO: MIH, can you file an issue in our repo and also bring this is up to the ICU-TC?
+
+MIH: Yes.
+
+RGN: EAO, are you saying that the ECMA-402 proposal for MessageFormat is influencing this requirement for multiple errors? Because ECMA-262 already includes an aggregate error object.
+
+EAO: Yes, this is uncomfortable for everybody, but the design is based on the idea that MessageFormat should not fail, as much as possible.
+
+RGN: True, but in the case of syntax errors, you –
+
+EAO: Yes, syntax errors are different.
+
+TIM: This means that #738 will be blocked on an issue that MIH will raise.
+
+MIH: Another idea why we shouldn’t force it in the spec is what RGN said about being lenient about how we choose an option from the design space. For example, RGN would be equally okay with having a solution that provides an API that includes 2 different functions (ex: format_strict and format_loose)