Skip to content

Commit 240fe22

Browse files
aphillipsaphillips
authored
Create notes-2024-10-14.md
1 parent 335b5b5 commit 240fe22

File tree

1 file changed

+298
-0
lines changed

1 file changed

+298
-0
lines changed

‎meetings/2024/notes-2024-10-14.md‎

Lines changed: 298 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,298 @@
1+
# 14 October 2024 | MessageFormat Working Group Teleconference
2+
3+
### Attendees
4+
5+
- Addison Phillips - Unicode (APP) -chair
6+
- Eemeli Aro - Mozilla (EAO)
7+
- Mihai Niță - Google (MIH)
8+
- Tim Chevalier - Igalia (TIM)
9+
- Richard Gibson - OpenJSF (RGN)
10+
- Matt Radbourne - Bloomberg (MRR)
11+
- Mark Davis - Google (MED)
12+
13+
14+
**Scribe:** MIH
15+
16+
17+
To request that the chair add an *issue* to the agenda, add the label `Agenda+` To request that the chair add an agenda item, send email to the message-format-wg group email.
18+
19+
## [**Agenda**](https://github.com/unicode-org/message-format-wg/wiki#agenda)
20+
21+
To request that the chair add an *issue* to the agenda, add the label `Agenda+` To request that the chair add an agenda item, send email to the message-format-wg group email.
22+
23+
## Topic: Info Share
24+
25+
(none)
26+
27+
## Topic: Schedule for Release
28+
29+
(none)
30+
31+
## Topic: `resolve-candidate`
32+
33+
*The following issues are proposed for resolve:*
34+
797
35+
786
36+
752
37+
703
38+
39+
## ** Topic: Agenda+ Topics**
40+
41+
### Bag of options vs. semantic skeletons
42+
43+
###
44+
45+
### Topic: Allow surrogates in content
46+
47+
*The previous consensus was to allow unpaired surrogate code points in text but not in literal or other constructs. Mihai points out some issues with this.*
48+
49+
MIH: My initial understanding was that we should allow this in localizable text, and literals are localizable text
50+
51+
### Topic: Add alternative designs to the design doc on function composition
52+
53+
*This topic should take only a minute. The discussion here is whether to merge PR 806, marking the design as “obsolete” or just close the PR.*
54+
55+
### : Topic: 799/786 Possible simplification of the data model/unify input/local definitions
56+
57+
***This was homework for this week.** The PR proposes to unify local and input declarations in the data model. We should accept or reject this proposal.*
58+
59+
### Topic: 603 We should not require \* if the variant keys exhaust all possibilities
60+
61+
*We should review this proposal and categorically accept or reject it for 46.1*
62+
63+
## ** Topic: PR Review**
64+
65+
*Timeboxed review of items ready for merge.*
66+
67+
| PR | Description | Recommendation |
68+
| ----- | ----- | ----- |
69+
| 906 | Allow surrogates in content | Discuss, Agenda+ |
70+
| 905 | Apply NFC normalization during :string key comparison | Merge |
71+
| 904 | Add tests for changes due to 885 (name/literal equality) | Merge |
72+
| 903 | Fix fallback value definition and use | Discuss |
73+
| 902 | Add tests for changes due to bidi/whitespace | Merge |
74+
| 901 | Clarify note about eager vs. lazy evaluation | Discuss |
75+
| 859 | \[DESIGN\] Number selection design refinements | Discuss |
76+
| 846 | Add u: options namespace | Discuss (634) |
77+
| 842 | Match numbers numerically | Discuss (Reject) |
78+
| 814 | Define function composition for date/time values | Discuss |
79+
| 806 | DESIGN: Add alternative designs to the design doc on function composition | Merge as Obsolete, Agenda+ |
80+
| 799 | Unify input and local declarations in model | Discuss (for 14 Oct) |
81+
| 798 | Define function composition for :string values | Discuss |
82+
| 584 | Add new terms to glossary | Discuss |
83+
84+
## Topic: Issue review
85+
86+
[https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues)
87+
88+
Currently we have 46 open (was 48 last time).
89+
90+
* 3 are (late for) LDML46
91+
* 15 are for 46.1
92+
* 11 are `Preview-Feedback`
93+
* 4 are `resolve-candidate` and proposed for close.
94+
* 3 are `Agenda+` and proposed for discussion.
95+
* None are ballots
96+
97+
| Issue | Description | Recommendation |
98+
| ----- | ----- | ----- |
99+
| | | |
100+
| | | |
101+
| | | |
102+
103+
## ** Topic: Design Status Review**
104+
105+
| Doc | Description | Status |
106+
| ----- | ----- | ----- |
107+
| bidi-usability | Manage bidi isolation | Accepted |
108+
| dataflow-composability | Data Flow for Composable Functions | Proposed |
109+
| function-composition-part-1 | Function Composition | Proposed |
110+
| maintaining-registry | Maintaining the function registry | Proposed, Discuss |
111+
| number-selection | Define how selection on numbers happens | Revision Proposed, Discuss |
112+
| selection-declaration | Define what effect (if any) the annotation of a selector has on subsequence placeholders | Proposed, Discuss (Agenda+) |
113+
| beauty-contest | Choose between syntax options | Obsolete |
114+
| selection-matching-options | Selection Matching Options (ballot) | Obsolete |
115+
| syntax-exploration-2 | Balloting of the revised syntax used in the Tech Preview | Obsolete |
116+
| variants | A collection of message examples which require a branching logic to handle grammatical variations | Obsolete |
117+
| formatted-parts | Define how format-to-parts works | Rejected |
118+
| quoted-literals | Document the rationale for including quoted literals in MF and for choosing the | as the quote symbol | Accepted |
119+
| builtin-registry-capabilities | Tech Preview default registry definition | Accepted |
120+
| code-mode-introducer | Choose the pattern for complex messages | Accepted |
121+
| data-driven-tests | Capture the planned approach for the test suite | Accepted |
122+
| default-registry-and-mf1-compatibility | Default Registry and MF1 Compatibility | Accepted |
123+
| delimiting-variant-patterns | Delimiting of Patterns in Complex Messages (Ballot) | Accepted |
124+
| error-handling | Decide whether and what implementations do after a runtime error | Accepted |
125+
| exact-match-selector-options | Choose the name for the “exact match” selector function (this is `:string`) | Accepted |
126+
| expression-attributes | Define how attributes may be attached to expressions | Accepted |
127+
| open-close-placeholders | Describe the use cases and requirements for placeholders that enclose parts of a pattern | Accepted |
128+
| overriding-extending-namespacing | Defines how externally-authored functions can appear in a message; how externally authored options can appear; and effect of namespacing | Accepted |
129+
| pattern-exterior-whitespace | Specify how whitespace inside of a pattern (at the start/end) works | Accepted |
130+
| string-selection-formatting | Define how selection and formatting of string values takes place. | Accepted |
131+
| variable-mutability | Describe how variables are named and how externally passed variables and internally defined variables interact | Accepted |
132+
133+
## ** Topic: AOB?**
134+
135+
EAO: I will probably not be available in the next two meetings
136+
137+
### Make bag of options for `` `:date` `` and `` `:time` `` optional in wait for semantic skeletons
138+
139+
MED: do we go out with nothing, or with an interim
140+
141+
EAO: can we have some time with these non-required, and make them required later
142+
143+
APP: we are talking about required options. Non required means you can still implement them.
144+
145+
APP: we decided early on to go with a bag of options because they can go back and forth to string skeletons. They are equivalent.
146+
147+
APP: what are we going to do with semantic skeletons they they come?
148+
149+
APP: we can’t really ship only with date / time style. We can’t say we are complete without something more flexible.
150+
151+
MED: I feel strongly that semantic skeletons are where we want to go.
152+
The current skeletons / bag of options would be a migration path.
153+
We can make them optional for now, and that gives us freedom to make them required, or keep them optional forever.
154+
155+
APP: but we do them as a package. If you implement, we implement all.
156+
157+
APP: anything else you are interested on in the agenda
158+
159+
### 603 We should not require \* if the variant keys exhaust all possibilities
160+
161+
MED: touching on the star, the issue of not requiring it means that things are not that robust.
162+
Messages build without a star you get into problems. It is kind of ugly to mix `\*` and `other`, but it is more robust.
163+
164+
EAO: the other case is the booleans. If you define true / false you will have nothing else ever.
165+
166+
APP: you need to know how to “explode” the cases.
167+
168+
MED: I think that we can back away from it if we require selectors to identify a default value.
169+
So at least the default value should be there.
170+
But has the downside that implementations need to know about all the selectors.
171+
172+
MIH: you mentioned we discussed it. Thought we reached a decision. Mentioning booleans. Seems like they have only two values, but some languages, like java, can have a null there. Localization tools have to know the functions. No way for tools to know without machine readable registry for now.
173+
174+
MED: eventually we need a machine readable registry.
175+
176+
MIH: for a while we don’t have it.
177+
178+
EAO: how an implementation communicates about custom functions is the language server work.
179+
When we have a selector like `:boolean` if there is a `{$x :boolean}`, if `$x` is not provided then the selection fails.
180+
181+
APP: probably best we can do.
182+
183+
EAO: with `\*` the selection would use that.
184+
185+
APP: in the end plural will be a pointer to CLDR
186+
Other selectors will likely behave the same.
187+
Machine readability needs to be able to include a “hey, look there”
188+
189+
MED: a lot of tools will take the messages in a source language, expand, translated, then compact.
190+
So in theory it can compact to `\* \* \*`.
191+
The star makes the tooling much more reliable.
192+
193+
APP: this is also a thing we can examine in the tech preview. We asked, we had no feedback.
194+
This can be tightened in the future, if we need to.
195+
We have a proposal on the table.
196+
197+
EAO: we can’t loosen it in the future.
198+
199+
APP: this is a data model. It is checked before we do function resolution.
200+
Which makes it tricky.
201+
202+
MED: requiring it is backward compatible. If we relax it in the future, the old messages are still valid.
203+
204+
EAO: I wanted to note that it looks like the proposal is rejected. Maybe for future consideration.
205+
206+
APP: any other topics you want to touch.
207+
208+
### 797 Create a PR for function interaction
209+
210+
Can I close this? Objections.
211+
212+
### 786 Possible simplification of the data model
213+
214+
APP: Find to resolve?
215+
216+
### 752 Improve test coverage for built-in function options
217+
218+
TIM: fin to close it?
219+
220+
### 793 Recommend not escaping all the things
221+
222+
TIM: no objections to close it
223+
224+
### 905 Apply NFC normalization during :string key comparison 905
225+
226+
227+
APP: Closing, approved by MED, TIM, APP
228+
229+
### 904 Add tests for changes due to 885 (name/literal equality)
230+
231+
APP: EAO approved, I have some minor comments
232+
233+
EAO: I left a comment.
234+
235+
### 902 Tests for bidi and whitespace
236+
237+
APP: EAO an me already approved. Comments?
238+
239+
### 806 DESIGN: Add alternative designs to the design doc on function composition
240+
241+
APP: we already did a lot of that work
242+
Do we want to merge?
243+
Some good work here. I can merge but mark it as obsolete.
244+
245+
### 895 Allowing surrogates
246+
247+
APP: there are areas that are localizable.
248+
One of the examples was with text in a placeholder.
249+
I tend to agree that the first pass through UTF-8 will break shoes characters.
250+
251+
APP: the proposal as you make it means we can use one in a key.
252+
253+
EAO: can I jump into this?
254+
Bad tooling can make mistakes in the text. Bot in literals.
255+
256+
APP: I tend to agree. If MF2 implementation would break in unpaired surrogates it might be a feature.
257+
258+
MIH: I don’t see a difference between text and localizable literals.
259+
If a tool is bad then it is bad in both.
260+
261+
TIM: for implementation I didn’t know what the correct behavior is when we find invalid surrogates.
262+
263+
APP: is the proposal to allow unpaired surrogates everywhere?
264+
265+
MIH: no, only in localizable text
266+
267+
EAO: is NFC well defined for unpaired surrogates?
268+
269+
APP: yes
270+
271+
RGN: I am 90% confident it normalizes to replacement character.
272+
273+
APP: I checked, NFC normalizes as itself
274+
275+
EAO: when you update this make sure to change all mentions of code units, to code points.
276+
277+
EAO: will you include a warning to not use unpaired surrogates?
278+
279+
MIH: yes
280+
281+
### 814 Define function composition for date/time values
282+
283+
EAO: can we merge that?
284+
285+
APP: that is not permanent? Is it a solution for now?
286+
287+
EAO: it allows us to change later.
288+
289+
APP: I think we will be back here when we get to semantic skeletons
290+
291+
MIH: we are introducing a strong type system, even when the underlying programming language does not do that. We basically say that ``:date`` returns a date kind of type, and it is an error to feed that into ``:time``, because it is a bad type.
292+
293+
### 799, 786 Unify input and local declarations in data model / \[FEEDBACK\] Possible simplification of the data model
294+
295+
MIH: Long discussion, unfortunately I was involved in it an didn’t manage to take notes.
296+
But the final decision was to drop it
297+
298+
APP: drop

0 commit comments

Comments
 (0)