- Addison Phillips - Unicode (APP) - chair
- Matt O'Conor - Bloomberg (MOC)
- Elango Cheran - Google (ECH)
- Eemeli Aro - Mozilla (EAO)
- Richard Gibson - OpenJSF (RGN)
- Harmit Goswami - Mozilla (HGO)
- Matt Radbourne - Bloomberg (MRR)
Scribe: MRR
EAO: We should ask the W3C tag for review.
APP: I pushed back until we were more done. I’ll take an action to ask them about that.
Let’s review the Task List:
APP: It’s in semi-priority order. I encourage people to make comments, say what’s missing.
ECH: After ICU4C/J deadlines, we said that we would revisit contentious issues (e.g. getting feedback), I reached out to the newly formed ECMA working group that can help us collect feedback. They responded saying “yes - what do you want to ask?”
EAO: The POV will be JavaScript (i.e. Intl.MessageFormat and the MF2 syntax underneath it). Michael [Prof in San Diego] may have capability and interest to put together survey around this. Timeline - 2-3 weeks from now. Other than that, TG5 has interest. Not questions to directly ask, but issues on which we want to get more input (e.g. what do we need to unblock the Intl.MessageFormat progress). I don’t want to be the only link to TC5.
ECH: I’m inching my way into this. It seems like a good way to help. It’s open for others to input. They wanted to back up and say ‘what are your goals?’
APP: We have different levels of feedback: Do you like the direction? (higher level) Specific technical questions
Timeboxed review of items ready for merge.
| PR | Description | Recommendation |
|---|---|---|
| #804 | Error handling | Discuss |
| #802 | Simplify terms in function-composition-part-1 design doc | Discuss |
| #801 | Fix comment about name | Merge |
| #800 | Use mappings for data model options and attributes | Discuss |
| #799 | Unify input and local declarations in model | Discuss |
| #798 | Define function composition for :string values | Discuss |
| #795 | Fix #782: give implementations more flexibility in error handling | Discuss |
| #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 | Discuss |
| #673 | Fix whitespace conformance to match UAX31 | Discuss; related to 781 |
| #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> | Depends on registry changes |
APP: I had one observation - It says you must supply errors/fallbackmessage/both. Is there any case where you only want the fallback? (i.e. no error)
ECH: When the other ECMA402 formatting APIs return a value, why is MF2 a special case? I think what [] said was ‘it’s good to have extra information’. But how actionable is this information? If applications depend on MF2, we can tear those applications down by raising an error. That was my initial thought.
APP: I can give people time to look - shall we talk next week?
RGN: There was discussion of opting in to strictness.
APP: It’s not that we require people to throw an exception and blow up. There must be a way to find out an error happened. If you just get a string, the only way to find out is to try and parse the string and find junk in it. We can do that without throwing. I can’t think of a case where you would just want the string to come.
EAO: The biggest difference between what MF2 depends and works on vs JavaScript.Intl is that it relies on user-provided data. This data is often coming to the runtime through translation - it’s not that the developer is providing it. This distance makes it much more likely for unpredictableerrors to enter into the experience. This needs to be accounted for in the API design we’re providing.
APP: I don’t disagree but the ‘must/should’ allows for all permutations without making you just hope it’s the right thing. It’s possible that you don’t want it to throw but that could be a consumer choice or a design choice by the implementer.
ECH: This discussion is making me think about what it means to provide “information about the error”. We need to find out that an error occurred - that’s effectively a boolean. That’s different to needing the error itself (e.g. a throwable in Java). We have the case of multiple errors on the table. It’s good to be really precise - I’d be OK with what APP said.
EAO: My position is that we should impose some requirements on implementations - what they must be able to provide. The way I would put the requirements - there must be a way to format the message that you get a fallback and that you must be able to format the message and get failure reported to you somehow. This would require behaviors from the implementer.
APP: Im staying away from saying ‘you have to throw’ - just ‘there is some way to find out’. A lot of people are going to wrap in a Message resource layer, which will handle this. That’s out of our scope though.
MOC: Are these criteria enforced simultaneously or independently.
EAO: Independently.
MOC: So you could have one or the other or both [yes]
ECH: Would it be worthwhile to spell that out in the design doc?
APP: Totally! To save us having this discussion again.
APP: EAO approved. I requested changes. I think there are other potential ways to get out of this box. I see this as an editorial change and suggest merging.
EAO: Agree - there’s more that can be done later.
[Merged]
APP: Bug #720 reported. This does not change our syntax in any way. Any objection to merging?
RGN: I’m in favour.
[Merged]
APP: I approved. Tim had a comment.
EAO: I think this will make it much easier to compare expressions with each other and removes error possibilities from the data model.
APP: Any objection? Anyone want more time?
ECH: We’re getting rid of an interface. What are the pros/cons? I normally think of interfaces as a good thing. [The attribute]
APP: That’s because we’re converting from an array to a map, which already has an interface. With the array, you have to walk the array to compare items, so I think it’s a simplification.
EAO: I don’t think we get rid of an interface, we just change. There’s an equal amount of type definition happening.
[Merged]
APP: No positive review yet. Has a comment from Tim and a merge conflict.
EAO: This is about identifying the fact that we want the syntax to have.input and .local as separate for clarity. In the data model, there is actually no use in keeping these separate. Having separate definitions is allowing us to present an error situation.
APP: Is one of the uses of the data model to present the message in a canonical form. How can you know if a declaration way local or not>
EAO: You can look if the declaration’s name matches the value arguments variable name. That must be valid for a .input and must not for a .local. Dropping this allows for a lot of simplification in the data model. We can and should remove the input and local declaration interfaces, which are combined into another declaration. The expression type is currently one of 4 different interfaces - it becomes one of 2 interfaces.
APP: We’ll try and get two ‘ship-its’ for next time.
APP: This the first step on untangling the conversations about function composition.
EAO: I’m looking to define this without a resolved value internally. If we start defining a resolved value is e.g. ‘a class like this with methods like these’ then we can change a lot about how we define these things. Otherwise we need to define things based on how they are used.
APP: My thinking has evolved. Tim’s design doc has the all-or-nothing approach. All = everything is transitive. String may not be the best function - it is mostly based on equality or stringifying. I suspect that in some cases you want to affect the operand and some you don’t. A function should say when it affects the operand. I think that transitivity of options falls into that. E.g. if I set the timezone in datetime, I just do it once, not every time.
EAO: I started with string because it is a minimal case - the behaviors for it are simple. We need to keep in mind that the behaviors are not spec behaviors. If the arg for :string is 42 (number), if the annotated value is used further along, what is it considered to be? With string, we can consider detail like this.
ECH: I was wondering how this compares with the discussion around function composition. It seems like this would be covered - there’s still some things to decide.
APP: EAO’s action item was to do this as a PR because we’ve had several abstract discussions and had a hard time agreeing on the right approach. This provides a spec implementation that we can discuss and decide if this is the right direction. We’ll merge when it’s right and then fix the design docs.
ECH: I would agree that string is not the right choice. Number formatting was a good example because the options come into play. (e.g. X is a number with options, Y is X, what should happen)
EAO:
.local $x = {42 :number}
.local $y = {$x :string}
.local $z = {:foo opt=$y}
Simple examples like this for string/number/integer/datetime/others, we can work out the specifics of the standard library functions and say that this behavior must be supported.
ECH: I have a different perspective. With number formatting I was taking more of a conservative approach. When you start mixing and matching functions, then all bets are off - don’t allow it. We can revisit but, right now, it’s easier to say don’t do it. The thing about using string, it’s the lowest common denominator type. This particular example makes it difficult to see how complicated things can get.
APP: I think maybe the first step is to establish the pattern - starting with string is ok. One of the patterns in the default registry doc: (e.g.) the result of a declaration or selector or formatter is that the operand is not affected.
ECH: What if local x was a string function and you’re passing it as an arg to $y, which is a number? Having to specify every single formatting function’s default behavior is one thing. We could say ‘mix and match’ for now because we can’t guarantee it would be sensible.
APP: We’ve established that people need to compose.
EAO: We need to be able to pass in complex values as option values. Fundamentally, the rules that come out of this aren’t that complicated. We’ll say “the value of a number function is a numeric value - it may have a non-empty set of formatting options coming with it”. This means that, if we accept these premises, the option values coming out are not necessarily the ones coming in.
APP: Action items here?
EAO: Are we OK with the current language be the sort of language that doesn’t specifically define what a resolved value is?
APP: I don’t want to uncork a formal definition if possible. We have to say what an output operand of a function is.
EAO: Is that done already? Maybe it’s not clear enough?
APP: We have to say concretely what a function definition must do, without specifically saying what it is. Also stating transitive options where applicable.
EAO: This is defined already but maybe more tersely than it needs to be (for string).
APP: Instead of ‘resolved value’, would it be better to say ‘resolve its value to be’?
EAO: Yes
APP: In more complex cases with number, it’s better than saying there’s a resolved value object that we need to say what’s type it is.
EAO: I think that’s what I’m trying to do. [Requests APP file a change suggestion for the above].
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 62 open (was 60 last time).
- 16 are Preview-Feedback
- 0 are resolve-candidate and proposed for close.
- 0 are Agenda+ and proposed for discussion.
| Doc | Description | Status |
|---|---|---|
| bidi-usability | Manage bidi isolation | Proposed |
| data-driven-tests | Capture the planned approach for the test suite | Proposed |
| error-handling | Decide whether and what implementations do after a runtime error | Proposed, NEW |
| expression-attributes | Define how attributes may be attached to expressions | Proposed |
| selection-declaration | Define what effect (if any) the annotation of a selector has on subsequence placeholders | Proposed |
| beauty-contest | Choose between syntax options | Obsolete |
| syntax-exploration-2 | Balloting of the revised syntax used in the Tech Preview | Obsolete |
| variants | A collection of message examples which require a branching logic to handle grammatical variations | Obsolete |
| formatted-parts | Define how format-to-parts works | NOT accepted |
| code-mode-introducer | Choose the pattern for complex messages | Accepted |
| quoted-literals | Document the rationale for including quoted literals in MF and for choosing the | as the quote symbol | Accepted |
| builtin-registry-capabilities | Tech Preview default registry definition | Accepted |
| default-registry-and-mf1-compatibility | Define the functions necessary for the tech preview | Accepted |
| delimiting-variant-patterns | Balloting of complex message handling | Accepted |
| exact-match-selector-options | Choose the name for the “exact match” selector function (this is :string) |
Accepted |
| number-selection | Define how selection on numbers happens | Accepted |
| open-close-placeholders | Describe the use cases and requirements for placeholders that enclose parts of a pattern | Accepted |
| overriding-extending-namespacing | Defines how externally-authored functions can appear in a message; how externally authored options can appear; and effect of namespacing | Accepted |
| pattern-exterior-whitespace | Specify how whitespace inside of a pattern (at the start/end) works | Accepted |
| string-selection-formatting | Define how selection and formatting of string values takes place. | Accepted |
| variable-mutability | Describe how variables are named and how externally passed variables and internally defined variables interact | Accepted |
MRR: What’s required for data-driven.
APP: In the PR, mark as accepted but don’t merge until we’ve discussed.
MOC: I want to capture discussions from the TC (with ECH) about CLDR data in this doc.
APP: We want to permit use of MF2 without CLDR data and be conformant, however that makes for very boring tests.
ECH: No disagreement there. There are tests in many places. Discussion in the ICU-TC about where this should live. CLDR would be the source of data for conformance and ICU? Any opinions?
EAO: One thought I had around testing - define a way to have tests that state there’s a way for a concatenation of messages to be described as an exact output from a formatter. One issue is that we’d need to define the options that can be passed to a number formatter, then we get into the discussion of whether we do this in the ICU way vs the JS way.
MOC: It seems like there’s some variability on how people should be approaching this, which could lead to inconsistent experiences.
APP: Every piece of the specification should be testable. There is the default registry, which gets us into trouble with CLDR data - :number and :datetime depend on their implementations, however inputs are defined and can be tested, options too. The actual output for a given locale is dependent on your implementation. For conformance, we don’t want to be dependent. It’s ties to specific versions of CLDR - when that gets updated, the output can change. Our tests don’t want to go to that.
EAO: We need a core test suite for the core specification. ICU is interested in a suite that tests conformance with data.
ECH: Since Tim and Mihai aren’t here I’ll put words in their mouths :) They didn't want to write tests [here] that are tied to specific formatter output. A unit test for MF2 shouldn’t depend on anything else. I think that Tim and Mihai would be in agreement.