Create notes-2025-02-17.md

Author: aphillips

meetings/2025/notes-2025-02-17.md

@@ -0,0 +1,280 @@
+# 17 February 2025 | MessageFormat Working Group Teleconference
+
+Attendees:
+
+- Addison Phillips \- Unicode (APP) \- chair  
+- Eemeli Aro \- Mozilla (EAO)  
+- Mark Davis \- Google (MED)  
+- Mihai Nita \- Google (MIH)  
+- Richard Gibson \- OpenJSF (RGN)  
+- Shane Carr \- Google (SCA)  
+- Manish मनीष Goregaokar
+
+
+**Scribe:** RGN  
+
+
+## Topic: Info Share, Project Planning
+
+## Topic: PR Review
+
+*Timeboxed review of items ready for merge.*
+
+| PR | Description | Recommendation |
+| ----- | ----- | ----- |
+| \#1016 | Require select option to be set by a literal value | Discuss; Merge |
+| \#1015 | Drop the notation, compactDisplay and numberingSystem options | Discuss; Merge |
+| \#1014 | Drop the u:locale option | Discuss |
+| \#1013 | Require digit size option to support values 0-99 | Discuss |
+| \#1012 | Define optionality separately for each u: option | Discuss; Merge |
+| \#1011 | Require prioritizing syntax and data model errors | Defer to 48 |
+| \#1010 | Fix normative language in Notes | Merge |
+| \#1008 | Rationalize name-char | Discuss; Merge |
+| \#1007 | Preparing the specification for LDML47 release | Discuss; Merge |
+
+## Topic: Housekeeping Issues from PR List
+
+*\#1007 modifies the stability policy by removing an item. Let’s discuss that change before approving. Let’s also discuss the chair’s proposal to punt \#1011 to v48.*
+
+### Activating the stability policy (\#1007)
+
+\> Updates to this specification will not remove any syntax provided in this version.
+
+APP: I propose removing it because it is ill-defined and already subsumed by other text. It could otherwise cause problems later.
+
+APP: Any objections?
+
+\[no objections\]
+
+### Require prioritising syntax & data model errors (\#1011)
+
+EAO: Would we be able to change SHOULD to MUST in the future? If so, then I’m comfortable deferring, otherwise not.
+
+MED: Because this is a runtime concern, that should be fine.
+
+## Topic: Status of u:locale (\#1014)
+
+*Questions have been raised about keeping u:locale in the specification. Let’s discuss options (keep as-is, make Draft, remove, etc.)*
+
+APP: I think it makes sense to keep this in draft, allowing it to follow our normal process.
+
+## EAO: For historical reasons, the design doc is “expression-attributes”.
+
+MIH: Do we still \_need\_ attributes?
+
+EAO: Yes.
+
+APP: And with an independent design doc.
+
+APP: Any objections to retracting specifically u:locale?
+
+\[no objections\]
+
+## EAO: PR \#1014 has relevant test changes.
+
+MED: I think the tests need annotation corresponding with the feature’s status.
+
+EAO: In past discussion, we wanted identifying keys for optional features.
+
+MED: That’s going beyond what I’m talking about here.
+
+APP: I’ll make an issue.
+
+MED: Tests can go later than Wednesday. Drafts don’t need to be marked as MAY, SHOULD, MUST, since that status is irrelevant (and can be changed)
+
+## Define optionality separately for each u: option (\#1012)
+
+EAO: Would anyone object to making u:dir a MUST?
+
+APP: That \_seems\_ fine to me.
+
+MED: Maybe not right now?
+
+EAO: PR \#1012 sets separate requirement levels for u:id, u:dir, and u:locale. It seems like u:dir should be required.
+
+MED: I’d like more time to explore the consequences of changing to MUST.
+
+EAO: u:dir ends up not on functions, but on the implementation.
+
+APP: The change would require that every function annotation supports u:dir.
+
+EAO: OK, let’s not require u:dir support right now.
+
+## Topic: Unquoted Literal Syntax (\#1008)
+
+## *Mark has proposed a change to the unquoted set of chars. Let’s see if we can close this.*
+
+## EAO: I’m fine with this, but don’t see the point of including ZWSP in \`name\`.
+
+MED: The name of that format character is misleading; it’s not really a space.
+
+APP: Is there a possible exploit because it’s invisible?
+
+MED: Both XML and MessageFormat allow invisible characters.
+
+EAO: The only such confusion is that it allows for name-char to visually appear at the start of a name.
+
+MED: ZWSP is not the only such character. Omitting it would not actually protect from that.
+
+EAO: I wanted to raise the concern, but now we can move on.
+
+RGN: I support stable identifiers. Seems like a reasonable spot to draw the line for cutting off future debate.
+
+APP: Possibly relevant to external discussions as well.
+
+EAO: If \<ZWSP, DIGIT NINE\> is a valid identifier, then why not just \<DIGIT NINE\>?
+
+MED: Tradition.
+
+EAO: We probably already have a superset of what any surrounding environment supports; making the superset even wider seems inconsequential. Even dot is probably fine because of the surrounding context.
+
+MED: Such an expansion could be made in the future.
+
+## Topic: LDML47 Release Finalization, Approval, and Balloting
+
+*The LDML47 release is upon us. The PRs necessary to release v47 will be considered in this call. We will also discuss whether/how to approve the release. ICU-TC has proposed that we stabilize the specification and the functions :string, :number, and :integer and **not** stabilize the other functions.*
+
+\[agreement to close PR Require digit size to support values 0-99 \#1013; its typo fix will be incorporated into \#1007\]
+
+## Topic: ICU4X Objections to option=$variable (\#1006)
+
+*The ICU4X Technical Committee has concerns about assigning option values using variables in certain instances. They have produced a document explaining their position \[[here](https://docs.google.com/document/d/1ZJ2v8URmNuJh5E5w_CdLwk0hqOkK8pVUe44YFQuc1nY/edit?usp=sharing_eip&ts=67af6b78)\]. Reserving time to discuss MFWG’s reaction to this. Please read their document prior to the call.*
+
+*Manish suggests:*  
+*For the purposes of the meeting today I think it is worth getting answers to two questions:*
+
+* *For the options ICU4X listed, does MFWG believe there are genuine use cases for allowing them to be set at run time via external input?*  
+* *If not, does it make sense to disallow them being set in such a way, or will that be confusing to users?*
+
+Manish: ICU4X is particular about loading data. The options are good, but being able to affect them at runtime is not aligned with our philosophy.
+
+APP: Your technical reasoning is good, but have generally been liberal about options.
+
+APP: We already have a PR regarding :number/:integer selection.
+
+APP: notation and compactDisplay are indeed a concern.
+
+APP: I think we can address everything you have raised, possibly without special pleading.
+
+MIH: For u:locale, I can imagine relevance to users speaking multiple languages, which would not be known at design time.
+
+MIH: Could this be chosen per-function?
+
+MED: I don’t find MIH’s use case to be compelling.
+
+MED: Number selection could apply to arabic vs. native number forms. Maybe this should be marked as draft for LDML47?
+
+MED: But selector should not be dynamic.
+
+EAO: There are very necessary use cases for continuing to support variables as option values.
+
+EAO: PR Require select option to be set by a literal value \#1016 is a concrete fix.
+
+EAO: Runtime dependencies are not limited to variables in option values, but also e.g. host objects.
+
+APP: I think the spec should note that some options might not support variable values.
+
+Manish: Tooling is a good analogy, because it can nudge translators in the right direction vs. the wrong direction.
+
+Manish: We have not encountered use cases that go against our document, though we would definitely like to know about any that exist because it will also affect non-MessageFormat ICU4X applications.
+
+EAO: Imagine formatting a datetime object that encompasses some options.
+
+EAO: Regarding APP’s suggestion, it would not be incorrect but is not necessary to note that functions can distinguish and reject variable option values.
+
+RGN: So this PR \#1016 is providing a new requirement that functions can observe that difference?
+
+EAO: Yes.
+
+MED: Going back to APP’s question, I think the main spec should make clear that a MessageFormat implementation provides functions with that information.
+
+EAO: I can do that in a \[non-normative\] followup to \#1016. But I would like to merge this PR ahead of that.
+
+MED: The indirect introduction of normative requirements should be avoided. This must be more prominent than some implication in the functions section.
+
+EAO: Can we agree on provisional acceptance?
+
+MED: A followup seems fine to me as long as the point is addressed.
+
+APP: Are there objections to merging \#1016?
+
+\[no objections\]
+
+RGN: Specifically, implementations must provide functions with information allowing them to distinguish literals vs. variables and alter their behavior accordingly (including, in some cases, rejecting one of those classes with an error).
+
+EAO: I may need to iterate on the followup text for things like \`.local $a \= …\` with \`.local $b \= $a\` and eager vs. lazy concerns.
+
+## Drop the notation, compactDisplay, & numberingSystem options (\#1015)
+
+MED: These could be dropped entirely, or marked as draft. There seems to be no preference in the group, so I think the chair gets to decide.
+
+SFC: This is not a concern for LDML 47, but there is a question about options vs. functions.
+
+APP: NumberFormat and DateTimeFormat have historically been jammed with options, but over time we have tended to move in the other direction. But it should be considered carefully, because we might end up with a lot of utility functions.
+
+EAO: I have a preference to remove these options for a clean slate.
+
+MED: \[agrees\]
+
+\[no objections\]
+
+## Topic: Remaining ICU4X concerns
+
+SFC: The proposal is still allowing variable references in options. Bringing in the now-deferred drafts in LDML 48 or later would result in an inconsistency between options that allow variables vs. those that don’t.
+
+APP: That’s now already the case because of \`select\`. But there is a further question about divergent support across \*implementations\*.
+
+EAO: The current text for [Digit Size Options](https://github.com/unicode-org/message-format-wg/blob/2727a5a7a7223b622f3b4755593258ca392515b3/spec/functions/number.md#digit-size-options) already allows implementations to not support variable values.
+
+MED: I think that’s reading too much into it. This goes back to RGN’s point… without the information to distinguish variables vs. literals, a variable whose contents were valid…
+
+EAO: But implementations were not \*forbidden\* from passing along that information.
+
+RGN: I don’t think that text supports a reading that interacts in any way with literal vs. variable input.
+
+EAO: The original intent here was to remain untyped.
+
+SFC: I think this relates entirely to draft functionality, but for the record: if something is a MAY or RECOMMENDED, ICU4X is unlikely to implement it.
+
+MED: The things that we want everyone to be able to depend upon need to be MUSTs.
+
+APP: We do have a few MAYs, but I’m pretty sure that ICU4X will allow them.
+
+SFC: I laid out some rules of thumb in my document and in issue comments.
+
+APP: Would you object to inclusion of your document in our repository?
+
+SFC: Let’s work it out over email, but in general I do support that.
+
+MED: It would be interesting to have a companion document providing some general context about the specification.
+
+EAO: The MAY text regarding digit size options would probably be better as SHOULD. If an implementation supports e.g. integer types, those should really be acceptable as digit size options.
+
+## Fix normative language in notes (\#1010)
+
+MED: I have some comments.
+
+EAO: I’m fine with accepting the suggestions and then merging.
+
+## Topic: Issue review
+
+[https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues)
+
+Currently we have 40 open (was 38 last time).
+
+* 13 are tagged for 47  
+* 12 are tagged for 48  
+* 3 are tagged “Seek-Feedback-in-Preview”  
+* 6 are tagged “Future”  
+* 14 are `Preview-Feedback`  
+* 5 are `resolve-candidate` and proposed for close.  
+* 4 are `Agenda+` and proposed for discussion (see below)  
+* 0 are ballots
+
+| Issue | Description | Recommendation |
+| ----- | ----- | ----- |
+| [935](https://github.com/unicode-org/message-format-wg/issues/935) | Well-formed vs. valid (particularly [https://github.com/unicode-org/message-format-wg/issues/935\#issuecomment-2529306693](https://github.com/unicode-org/message-format-wg/issues/935#issuecomment-2529306693))  | Discuss |
+| [724](https://github.com/unicode-org/message-format-wg/issues/724) | Message Format Unquoted Literals | Discuss |
+| \#866 | CLDR semantic datetime skeleton spec is nearly ready and MF2 should use it | Discuss |
+|  |  |  |
+