Create notes-2024-06-17.md

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

@@ -0,0 +1,192 @@
+# 17 June 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Tim Chevalier - Igalia (TIM)
+- Elango Cheran - Google (ECH)
+- Staś Małolepszy - Google (STA)
+- Eemeli Aro - Mozilla (EAO)
+- Steven R. Loomis - Code Hive Tx (SRL)
+- Richard Gibson - OpenJSF (RGN)
+
+
+
+Scribe: ECH
+
+## Topic: Info Share
+
+Unicode: Bidi workshop announcement
+
+https://www.unicode.org/events/
+https://us06web.zoom.us/webinar/register/7317157843728/WN_wtqmIMS-ScasVMSqMCUYOw#/registration
+
+
+Attend TC39/TG5 call on designing feedback solicitation for MF2
+
+ - https://github.com/tc39/tg5/issues/3 
+
+TC39 last week
+
+EAO: 
+Error handling and fallback of Intl.MessageFormat was discussed. During the discussion we considered alternative API shapes. Specifically, moving the error callback behavior definition from format method call to the constructor options. We did consider changing the return value coming from the format method(s) which would have both the formatted value and the errors. We considered other related API shapes. Mention here because potentially relevant, but core is that ultimate API should allow for getting a formatted fallback result and for getting the errors that come out of formatting. API here is Intl.MF. These would be required by the 
+
+Didn’t identify any new requirements and no changes needed.
+
+## Topic: Tech Preview
+Let’s review the Task List:
+
+https://github.com/unicode-org/message-format-wg/wiki/Things-That-Need-Doing
+
+
+## Topic: PR Review
+Timeboxed review of items ready for merge.
+
+|  PR  |                            Description                            |              Recommendation             |
+|:----:|:-----------------------------------------------------------------:|:---------------------------------------:|
+| #806 | DESIGN: Add alternative designs to function composition           | Discuss                                 |
+| #804 | Error handling                                                    | Discuss                                 |
+| #799 | Unify input and local declarations in model                       | Merge                                   |
+| #798 | Define function composition for :string values                    | Discuss                                 |
+| #795 | Fix #782: give implementations more flexibility in error handling | Blocked by #804                         |
+| #780 | [DESIGN] Contextual options in the `u:` namespace                 | Discuss                                 |
+| #744 | Fix design doc                                                    | Merge (approved, waiting on bearfriend) |
+| #728 | Add "resolved values" section to formatting                       | Blocked by #806 and #798                |
+| #673 | Fix whitespace conformance to match UAX31                         | Discuss (no longer blocked)             |
+| #646 | Update spec as if PR #645 were accepted                           | Depends on 645                          |
+| #634 | Design doc to capture registry maintenance                        | Discuss                                 |
+| #616 | Add docs/design etc.                                              | Discuss (Reject?)                       |
+| #584 | Add new terms to glossary                                         | Discuss                                 |
+| #558 | Add <when> to help select the right <match>           | Discuss                                 |
+
+
+### #807
+
+EAO: I looked at this. Everything looks good. It’s just documented what we have already 
+
+ECH: Yes, everything looks good, nothing controversial.
+
+SRL: How does the MF2 spec plug into CLDR LDML in future releases of CLDR?
+
+APP: In CLDR v46, we’ll convert the MF2 spec files into a single document, and we’ll convert that into HTML in the same way for CLDR specs.
+
+SRL: That answers my question for the CLDR v46 timeframe, which is to repeat the same process.
+
+APP: I hope we won’t have too much effort after that. There will be changes to the registry from release to release.
+
+SRL: We should discuss the registry maintenance process with the other TCs. I wanted to do a temperature check on those processes.
+
+### #806
+
+TIM: It’s just one document. I turned it back into a draft based on EAO’s comments. I want to go back to #798. I think what EAO proposed in #798 is close to what’s necessary for composition to work.
+
+APP: What we discussed before was to work backwards by showing composition working in some spec, and then work the design out of that.
+
+ECH: Is that #728 or #798?
+
+APP: #728 references #798 and #806. Given that we have 3 PRs on the topic, how do we want to resolve getting function composition to work?
+
+EAO: The idea was that if we work out specifically how `:string` should work, we could work out how `:number` and then map out what could be in the spec about the composition of these functions.
+
+APP: I don’t think that my thinking has evolved much since the last time we discussed. There are a couple of key things: whether the return value convers up the operand or changes the operand behind a specific name, and `:string` doesn’t do anything to items in the same way.
+
+EAO: `:string` does stringify them, and that is an operation.
+
+APP: THat’s one thing, whether that does happen or can happen. Does it override the operand? If you’re calling `:uppercase`, you probably want that. My thought is that some options are sticky or not. To EAO’s point, when you get to `:integer` and `:date`, things will get tricky.
+
+EAO: This is the point where we think about expression attributes, how does `:u:locale` get passed through? But that is a thing that we can leave out from consideration from `:string`. We have to take care to preserver 
+
+ECH: The last time we talked about 798 / function composition. We had a very cautious take, where I said that it gets really tricky because of defining the return types. I saw Tim’s comment about type system, inferring what the resolved type is. We play it safe by not having function composition. Just merge the options. Asking for others to help me think through this. Need for linguistic features such as those Stas was talking about. 
+
+EAO: It would be very useful to define it in the MF2 spec. We want this in Intl.MessageFormat, so we 
+
+STA: To answer ECH’s question, merging types and options is one use case. In my opinion, for enabling interesting grammatical features, we will need to compose different types. It gets quite complex, it requires developing a complex type system to know what is valid or not. My take is that we don’t need to know it. Instead, we just leave that up to the message authors and function authors. We assume that they know what they’re doing.
+
+APP: I more or less agree with STA. I agree with EAO because people will have expectations, unless we do not permit chining, such as a sequence of `.locals` where the output of one declaration does not influence the output of another when it is used as the input to it, which would be surprising to the user. People want to do composition, so I think it’s consistent with what people want to do. I think we can finesse for the built in functions is to say that the resolved value of `:string` is an implementation defined type, and the type of the resolved value for `:number` is implementation defined. We don’t need to specify it because the implementation will take care of it, and that’s a value input to another function.
+
+EAO: I would posit that what you get out of a `:string` is a string type, but rather that what you get is something that wraps a string object. They have a value, they have options, and you can do stuff with them.
+
+STA: I think I agree with both APP and EAO. To add to what APP said, we don’t need to define exact exactly what the value type is. In the case of `:number`, it should wrap a number, but it should also preserve `minNumFractionDigits`.
+
+APP: I think #798 doesn’t go far enough because `:string` isn’t interesting enough. I would like `:datetime` because time zone is interesting.
+
+ECH: 
+
+EAO: Note an action on me to write down how composition would work for `:datetime` and `:time`.  ECH, we don’t need to have implementations define what interface they use for the return values. We just need to have the spec 
+
+TIM: I think it would be useful to have `:datetime` but I think we shouldn’t jump to it quite yet. I have a comment on #798 where I give an example that the language doesn’t quite handle. I want the spec to be fully consistent before we take on a harder example.
+
+APP: So you want us to handle with `:string` before working on something else.
+
+TIM: Yes, I think that makes sense. I think the definition that we have doesn’t quite seem right. I’m not sure what to suggest concretely, but I think we should work on it.
+
+APP: If we worked on examples with `:datetime` in a separate PR, would that be okay.
+
+TIM: That sounds okay, so long as we don’t merge things.
+
+APP: We won’t merge things because we aren’t decided on the model.
+
+
+### #799
+
+TIM: The difference between this PR and the one with #800 options being unique is that the implementation would have to do 2 passes, with the parser having to do the work of checking for errors.
+
+EAO: Can you clarify how this requires 2 passes?
+
+TIM: If you’re going to catch all duplicate declarations in the parser, then you need to carry around an environment in the parser. The other way is to first check for a special case, and then go back and ____.
+
+APP: When you parse a message into a data model, you’re already checking for validity, right?
+
+EAO: I think I understand what TIM is saying. You might have
+
+```
+```
+
+TIM: Right, we’re in agreement. You would have the same error sometimes emitted by the parser, and sometimes emitted only after the parser fully constructs the data model.
+
+EAO: Okay, I don’t think that’s an undue burden.
+
+TIM: Maybe that is a matter preference. What I’m against is that this eliminates some of the errors that an implementation can possibly emit.
+
+APP: Are there ways of getting those errors out?
+
+EAO: No.
+
+APP: Are there benefits of maintaining the difference between 
+
+TIM: The benefit of keeping them different. I want the parser to be as simple as possible. I want the errors to be computed on a fully constructed data model. Allowing `.input` and `.local` being separate allows me to do so.
+
+EAO: THese being separate is why we have so many `Expression` definitions in the spec. This is why we have a `ValueExpression`. We could instead have one unified `Expression` definition.
+
+APP: How do we want to resolve this?
+
+TIM: It would be good to get other opinions.
+
+APP: It would be good to get MIH’s opinion.
+
+EAO: I am in no rush, so this can wait.
+
+### #673
+
+APP: This is a change to whitespace handling to support Bidi in order to conform to Unicode UAX 31. We got Tech Preview feedback asking why we are not handling Pattern Exterior Whitespace, I will handle that separately, but not related to this issue. I want people to take a look.
+
+EAO: I want us to have a solution for syntax bidi support first before proceeding with this PR.
+
+## Topic: Issue review
+Let’s close all of the issues
+https://github.com/unicode-org/message-format-wg/issues?q=is%3Aissue+is%3Aopen+label%3ALDML45
+
+https://github.com/unicode-org/message-format-wg/issues
+Currently we have 61 open (was 62 last time).
+16 are Preview-Feedback
+0 are resolve-candidate and proposed for close.
+0 are Agenda+ and proposed for discussion.
+
+
+## Topic: Design Status Review
+
+
+
+## Topic: AOB?
+
+
+