Create notes-2024-09-09.md

Author: aphillips

meetings/2024/notes-2024-09-09.md

@@ -0,0 +1,167 @@
+# 9 September 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Mihai Niță - Google (MIH)
+- Eemeli Aro - Mozilla (EAO)
+- Mark Davis - Google (MED)
+- Tim Chevalier - Igalia (TIM)
+- Richard Gibson - OpenJSF (RGN)
+- Harmit Goswami - Mozilla (HGO)
+
+Scribe: HGO
+
+## Topic: LDML46 and the end of Technical Preview
+_The v46 release is upcoming. There is also a desire to finish the 2.0 release (exit technical preview). Let’s discuss the practical considerations for doing both, including the possibility of a 46.1. This is also the section of the meeting in which we’ll set out the goals for the next 2-3 days._
+
+[APP]: Current plan for #46 is to bookmark where we’re at and run the spec out. We still call it a technical preview but release out to-date work
+
+[MED]: Deadline is 25th for tech preview, we need time for back-and-forth and review, I don’t see time for that so we should target end of November to be done in this community
+
+[EAO]: Why do we need to complete this in this calendar year?
+
+[MED]: Funding issues, also without a forcing factor, this group might take ages. A deadline helps us to get done
+
+[EAO]: My concern with finishing the tech preview is that we will need to await on external inputs (Although I like the deadline)
+
+[MED]: If this is done properly, we can fix problems later (if it’s done properly). Trying to perfect it now is risky.
+
+[APP]: I think we can do enough to go ask the larger community prior to finishing the core issues remaining. We can run off a copy of #46 as a ‘stake in the ground’
+
+[MED]: Sounds good, we don't want to force things into the tech preview since there’s only a week. 
+
+[EAO]: Wanted to clarify the parts of the spec that are not able to be complete within the week. If people outside this group have different thoughts, I’m concerned the balance between opinions and decisions we can make will get out of hand, and worst-case can lead to a v3 release
+
+[APP]: Most of the concerns are regarding syntax. I agree, but people who don’t like the syntax will either have to live with it or create their own standard. We’ve reached our goals with what we wanted to accomplish with the syntax, other people can discuss whitespace, etc., but that won’t be in MF2. We can’t keep opening that box.
+
+[APP]: On monday, we’ll finalize what to add in, and submit on wednesday.
+
+## Topic: PR Review
+Timeboxed review of items ready for merge.
+
+
+## Topic: … (#879)
+[Merged]
+
+## Topic: … (#878)
+[MED and EAO approve, merged]
+
+
+## Topic: Selection-declaration (#824, #873, #872)
+_Discuss the design options seeking WG consensus. Timeboxed to 15 minutes._
+
+- https://github.com/unicode-org/message-format-wg/blob/main/exploration/selection-declaration.md 
+- https://github.com/unicode-org/message-format-wg/issues/873
+- https://github.com/unicode-org/message-format-wg/issues/872
+
+[APP]: There wasn’t a consensus on #873, but solution F seems to be getting an emergent consensus. I think that’s the proposal on the table, any challenges?
+
+[MED]: I think it’s suboptimal, but can be extensively modified in the future (see solution E). I think it’s good for release 46.
+
+[APP]: I’m also unhappy with it currently
+
+[EAO]: If there’s a desire to make this backwards extensible, then we need to reserve the space in the syntax, opposed to what we currently do
+
+[APP]: Or we look at our stability guarantee to see if we can make that change
+
+[MED]: The key thing people want is backwards compatibility
+
+[EAO]: In our current stability policy, the 2.0 parser should parse without syntax error a message made in 2.1 … 2.n version. So then I feel we must reserve the space
+
+[MED]: I think it’s a mistake to promise the syntax is forwards and backwards compatible, since that ties our hands for the future. Changing forward compatibility needs a good reason, but tying our hands now can be bad, as I’ve seen in my career
+
+[EAO]: I’d be okay with no forwards compatibility. This also lets us drop all the reserved structures from the syntax.
+
+[MIH]: I have mixed feelings about dropping. L10n tools would work, which is the main benefit. On the other hand, currently having reserved structures is clunky, so I’m okay with removing forwards compatibility
+
+[APP]: I think it’s a reasonable evil. I doubt we’ll use the structure but I could be wrong. 
+
+[EAO]: I’d be okay with losing forwards compatibility, partly due to this, but also because it’ll help us simplify a lot, and can get rid of all the reserved stuff. Effectively, everything that’s an error can be fixed later. It’d also make me less unhappy about rushing this out of the tech preview, since we have more options in the future
+
+[APP]: We’re suggesting that we can make additions to the syntax that won’t break your compatibility? [All: yes]
+
+[APP]: Okay so we need to rework our guarantee (MED: to guarantee backwards compat, but not forwards), remove reserved structures, and move forward with solution F? [MED]: Yup [APP]: EAO, we should do a PR for solution F first, then make 2 additional PRs
+
+## Topic: Disallow “whitespace or special char” prefixed `.` in reserved-statement’s body (#840)
+_Discuss making this technical change in the reserved-statement syntax._
+
+[APP]: Now out of scope!
+
+## Topic: Bidi design (#811)
+_Bidi and whitespace options need to be discussed in light of the design document._
+
+https://github.com/unicode-org/message-format-wg/blob/main/exploration/bidi-usability.md
+
+
+[APP]: A piece of homework for this topic was to review the ALM mark, which has an effect when used BEFORE a sequence of characters, but not when you add it to the end of a token. The way we use strong characters in the syntax, there’s not many ways you can incorporate ALM into it.
+
+[EAO]: So you propose we drop ALM from the allowed things? 
+
+[APP]: It’s an allowed character but not allowed in the syntax
+
+…
+
+
+## Topic: Standard, Optional, and Unicode Namespace Function Set maintenance (#634) [was “registry maintenance”]
+_This is the function registry maintenance procedure design. Let’s review with an eye towards using as a template for other work._
+
+[APP]: Should I add this in as proposed and we iterate later? [No objections]
+
+## Topic: Uniqueness (#869, #847)
+_String equality (used in key matching or operand uniqueness) is affected by Unicode Normalization concerns. We need to decide whether to require a specific normalization form (typically NFC) or whether we warn users about the consequences of using denormalized values._
+
+[APP]: We should address string equality, given the nature of Unicode. 
+
+[EAO]: Mentioning that we have option and attribute names checking for uniqueness
+
+[MIH]: My take is that I strongly favor comparing strings as they are without normalization. If you want to normalize, you are free to do it outside, but in terms of preprocessing, what gets to MF2 is processed as is.
+
+[MED]: Almost every process nowadays has access to NFC normalization, if the dataset is small. You can do a very quick check to see if a text looks suspicious or not. I’m more worried about odd errors hitting people, since one implementation normalizes and another does not. This won’t affect European languages as much, but it’ll hit other languages a lot
+
+[APP]: I’ve always wanted people to check for normalization. If we want broad adoption, not insisting on normalization will help, but then we have to warn people that naming variables “options” and “operand”, etc. is a bad idea. 
+
+[MED]: I see two issues. One, if all comparisons are within MF2 itself, and the second, if it depends on parameters and whether or not the parameters are normalized. I think it’s a mistake not to have a ‘SHOULD’ that comparisons should be done with normalization if possible. 
+
+[EAO]: Agree with MED, SHOULD is good but MUST is too much of a fight
+
+[APP]: Should is hard to test though
+
+[MED]: I don’t think it’s too hard, you can easily provide such test cases. You can mark the test cases as they’re SHOULD 
+
+[APP]: If we give authoring guidance that you should use normalized values, but the implementation doesn’t require normalization, then you can get yourself into trouble since it may sometimes work and other times won't. If you write a normalization-sensitive message, then it’s liable to cause problems, and there should be a warning
+
+[EAO]: I still think we should have a SHOULD. In the spec, you can get noticeable differences in behavior between normalized and non-normalized messages. 
+
+[APP]: Agreed, it should be given to the author. 
+
+[MED]: If we don’t go for MUST, then we should go with ‘MF2 text should be normalized with NFC, and parameters should be compared with normalization’. There can also be a section of the site that talks about implementation features, and this isn’t as formal so can be modified easily over time.
+
+[APP]: Normalizing the whole message is a bad idea since we have quoted text pieces that we promise as verbatim. That’s why I say it should be inside the comparison. I understand EAOs point, but if some messages behave differently in different environments, then I think it’s okay to just put a warning sticker there.
+
+[EAO]: It’s either we enforce with a MUST, or recommend with SHOULD, and handle the diverging corner cases
+
+[MED]: Agreed. The SHOULD should be put on building the message and comparisons.
+
+[MIH]: We still have to say the comparison should be normalized away. The comparison should be there no matter what. As an implementer, I don't really care since I implement on top of ICU. I’m still reluctant to ask for normalization behavior at runtime, but whatever
+
+[EAO]: Comparisons is the only place we should put the SHOULD, since that’s the only thing we control [All agree]
+
+[EAO]: We might also want to include a definition for ‘unique’ and ‘duplicate’, so we can point to those definitions in the PR
+
+[MIH]: I’m reluctant to claim a user should normalize an ArgMap, it’s just not that obvious. There might be use-cases where I want the denormalized form, and I can imagine a use-case
+
+[EAO]: My implementation plan won’t include normalizing the ArgMap, since it’ll be ASCII only.
+
+
+## Topic: Issue review
+https://github.com/unicode-org/message-format-wg/issues
+Currently we have 56 open (was 60 last time).
+- 14 are Preview-Feedback
+- 1 is resolve-candidate and proposed for close.
+- 3 are Agenda+ and proposed for discussion.
+- 1 is a ballot
+
+
+
+## Topic: AOB?
+