unicode-org · romulocintra · Jun 1, 2020 · May 19, 2020 · May 30, 2020 · Jun 1, 2020
diff --git a/meetings/2020/notes-2020-05-18.md b/meetings/2020/notes-2020-05-18.md
@@ -0,0 +1,282 @@
+#### May 18 Attendees:
+- Elango Cheran - Google (ECH)
+- Pablo Velez - Expedia (PAV)
+- George Rhoten - Apple (GWR)
+- Rafael Xavier de Souza - PayPal / OpenJSF (RXS)
+- Romulo Cintra - CaixaBank (RCA)
+- Staś Małolepszy - Mozilla (SMY)
+- Nicolas Bouvrette - Expedia (NIC)
+- Addison Phillips - Amazon (APP)
+- David Filip - ADAPT Centre at Trinity College Dublin (DAF) 
+- Eemeli Aro - OpenJSF (EAO)
+- Mihai Niță - Google (MIH)
+- Zibi Braniecki - Mozilla (ZBI)
+- Nick Felker - Google (NFR)
+- Richard Gibson - OpenJSF (RGN)
+- Shane F. Carr - Google (SFC)
+
+
+## MessageFormat Working Group Contacts: 
+
+- [Mailing list](https://groups.google.com/a/chromium.org/forum/#!forum/message-format-wg)
+
+
+
+## Next Meeting
+
+June 22, 10am PDT (6pm GMT)
+
+## Agenda
+- [ Agenda on Github ](https://github.com/unicode-org/message-format-wg/issues/82)
+
+Easy way to volunteer to participate in Chair Group :  [Link](https://github.com/unicode-org/message-format-wg/pull/70)
+
+
+## Updates from Chair Group Meetings
+ECH: provided a refresher on TCQ which we discussed adding to our documentation.
+
+RCA mentioned that the chair group meeting would be moved the week after the non-chair meeting to keep better context around previous discussions.
+
+### Goals and Non-Goals(Cont.)#59
+https://github.com/unicode-org/message-format-wg/issues/59
+
+RCA: Speaker is SMY
+
+SMY: Thanks for Git comments.  Vision conflicting with deliverables. Proposing 6 goals, high-level and generic, for the vision proposal to the working group. Next section 4 deliverables. For non-goals added statements of what we want to do instead. This document should be the summary of our thinking, but can be revised. But as a group agree on this direction.
+
+ECH displaying PR.
+
+SMY: The six goals are organized in 3 main groups: 1-2-3 around linguistics and structure, more grammatical expression and metadata in translation; 4-5 around industry goals and interoperability, deciding on what formats beyond XLIFF and enable integration with existing TMS; and 6 is a high level one, making the standard a building block. Something that can be used by others. 
+
+This was a summary of the goals. Next move to deliverables.
+
+ECH: Checking questions
+
+EAO: if we mention XLIFF we should also include existing formats.
+
+SMY: Good point. We discussed backwards compatibility last time. 
+
+EAO: Another option is to drop XLIFF from goals. 
+
+SMY: This could be an option to avoid controversies.
+
+DAF: About relationship with XLIFF. Mapping required for roundtrip of localization. We dont want to be too specific, but mapping is critical. 
+
+ECH: Asking DAF to make it a topic to discuss.
+
+ECH: Suggested bullet point changes.
+
+MIH: In the current proposal, merge 4-5 or just keep 5. XLIFF is about integrating with CAT tools. With 4 we solve 5.
+
+Another proposal, if we are missing today, to control formats (date, times). 
+
+ECH: People have opinions. There is a blue button to discuss topics.
+
+APP: Think there’s a linkage between XLIFF and interchangeability with other formats. Agree with insertive formatting observation.
+
+RCA: We should leave XLIFF open. Even if we have a strong relationship with this format and even it becomes the primary format first, we should leave it open so as to get stuck with one format.
+
+ECH: Asked David to talk about XLIFF as a topic.
+
+NIC: Keep number 5 is enough. If we have to use XLIFF, fine, but more important to be compatible.
+
+ECH: Asking David to talk about this topic.
+
+DAF: Best way to discuss this topic is having the mapping.
+
+ECH: It seems there’s an agreement. As proposed by NIC to remove 4 and start with XLIFF.
+
+APP: XLIFF is good for a specific translation unit. But we may need to have a mapping with larger units, like plurals. XLIFF may not provide all resources needed. as we introduce these structures, how do we pass these new units into a TMS?
+
+GWR: Converting grammatical number handling not explicit as XLIFF, and APP is correct about being explicit.
+
+APP: The challenge is the mapping for everyone to use it the same way. 
+
+RCA: Is it worth mentioning another format (SSML) in the goals? Probably another topic.
+
+GMR: Maybe another output format.
+
+ECH: Let's keep that one for later. EAO is next.
+
+EAO: If we are talking about compatibility with XLIFF, we need to be explicit of this compatibility. We should aim/hope for backwards compatibility, not to get committed to this format.
+
+ECH: Next is MIH.
+
+MIH: We shouldn't debate too much now about XLIFF. We should keep goals high-level. Valid topic but not for now.
+
+SMY: Conversion can be approached differently. Torned about 4 and 5. Lets keep mapping as a deliverable, this mapping to XLIFF is what will help people follow the use correctly.
+
+ECH: People to keep their comments tracked in the chat. We will try to add them to the doc.
+
+DAF: Representing OASIS XLIFF https://www.oasis-open.org/apps/org/workgroup/xliff/ and XLIFF OMOS https://www.oasis-open.org/apps/org/workgroup/xliff-omos/ TCs in Unicode. I believe the high-level goal is to complete localization roundtrip. TMS dont have interoperability, you dont want to deal on this one-by-one. Only way to achieve it is with XLIFF. The goal is to have a data model behind this roundtrip and I believe having an XLIFF mapping is critical. posted in chat a link https://galaglobal.github.io/TAPICC/T1/WG3/rs01/XLIFF-EM-BP-V1.0-rs01.xhtml
+This is extraction and merging guidance for content owners, basically how to make sure that you roundtrip your content including inline markup through an XLIFF 2 roundtrip
+
+ECH: next is a point of order from RCA.
+
+RCA: It seems points 4 and 5 are talking too much time. We should decide if to keep it like this or what to change to these points, so we can move with the other points.
+
+ECH: I agree. Skip clarifying resolutions. Moving to point 2 from SMY.
+
+SMY: Agree. Merge goals 4 and 5. We meet every month to find something usable for the localization roundtrip. Lets leave the mapping as a deliverable. The value of this deliverable is something that can be integrated with a TMS.
+
+ECH: This is your PR. Feel free to move forward and do the changes proposed.
+
+SMY: Ok going to go ahead and make changes in PR. 
+
+ECH: Clarify this is about making changes to 4 and keeping 5. 
+
+SMY: 4 really comes 5 as MIH mentioned. So lets keep 5.
+
+DAF: Also replace CAT tools/TMS with L10n roundtrip.
+
+ECH: K we are moving to another topic as we have clarified the XLIFF topic. APP is next.
+
+APP: Too much talk about formats, not about functionality. We may need a goal about functionality and interoperability with APIs for example.
+
+SMY: This was planned to be captured in deliverable 4. But I meant it vague enough as previously we were cautious about talking about specific APIs or what methods to use. 
+
+ECH: What deliverables do you refer to with the previous?
+
+SMY: Deliverable number 4 is about run-time specifications. Not sure if we want to go that far and should be left open. APP do you agree deliverable 4 is enough?
+
+APP: It does say specification but we need some number for acceptance criteria. We may have multiple implementations for ICU.
+
+GWR: From my experience this may not work with ICU.
+
+NIC: Agree with GWR. Not sure if this is the goal for this group. We should have a well documented standard, sandbox and library. The rest should be defined by other folks.
+
+ECH: Next is MIH.
+
+MIH: Not sure if its comments or not. We should do prototyping in different languages and see if it is working. But do we want to make this part of deliverables?
+
+ECH: Next is SMY.
+
+SMY: On the topic of API, we may want to implement a reference implementation. What is the expected outcome? Consider error scenarios. We need to be clear and definitive about how this works. 
+
+ZBI: While I understand we’re not interested in reference implementation as a goal, but hope to have aspirational goals beyond API calls. Consider voice over systems. We should aspire to support multiple user-interface models. We need a quick loop of prototyping and verifying- beyond APIs.
+
+ECH: As SMY goals are not set in stone.
+
+SMY: Lets keep this modern ‘uses’ in mind. The first 3 goals should capture these models. Allow for a greater expression in natural language.
+
+ECH: We havent put a timebox for goals and non-goals. How much more time should we extend on this? RCA proposes 10 more minutes.
+
+Keep going. We need to close this today.
+
+RCA: Agree with ZBI. Keep final implementations as POCs driven by the community. We are responsible for a base implementation, but we are not responsible for maintaining these multiple implementations now- maybe later in our roadmap.
+
+ECH: APP commented lack of implementation is a problem.
+
+GWR: APP are on similar boats. We should have a single reference implementation. Just one programming language to prove it works. But it shouldn't be forced into ICU. It has a lot of limitations. About 3MB per language to handle grammatical properties and inflection mappings for example. This is a consideration not to be constrained by ICU, which may not want to handle all this data by default.
+
+APP: I’m interested in ICU as a vehicle, part of my Amazon framework. But although not restrained to it, I also dont see why we shouldnt consider it here.
+
+ECH: Not taking a position about ICU. 
+
+ZBI: One way out is to have a POC (without saying it explicitly in the goals in one dynamic language). I prefer open source languages, but we could use others like from Apple. 
+
+SMY: On the topic of backwards compatibility. We could put it as an explicit goal. What does the team think?
+
+APP: Its easy forward compatibility, but we shouldnt look backwards. Dont want to be restricted that way. Better to have a way to convert all messages forward in a certain way.
+
+DAF: Agree with APP. We already had this discussion. The goal is to design it so its future proof. It doesnt belong in goals nor deliverables.
+
+ECH: We have 25m left. 
+
+SMY: Clarifying question- maybe used wrong terms. What I was aiming to put in the goals/deliverables, my idea was to add that messages could be migrated from format 1 to format 2. Is that forward or backward compatibility?
+
+ECH: What do you think about DAF that is more strategy than goal?
+
+SMY: To consider it.
+
+ECH: MIH is next with POC as a deliverable for some specific languages.
+
+MIH: We may capture the POC idea in the deliverables. Lets get the bullets points right.
+
+SMY: Agree.
+
+DAF: What is in scope is conformance implementation. Not full a POC- should be a 3rd party.
+
+APP: We should be looking for multiple implementations.
+
+DAF: We should encourage implementations by members and other stakeholders, even consider a certain number of implementations a success criteria, but implementations are not deliverables of the WG.
+
+APP: A success criteria is for us to demonstrate them. About backwards compatibility, I want to be able to do everything I used to do. 
+
+MIH: We should document what were bad ideas for backwards compatibility.
+
+ECH: DAF asking about adding XLIFF as a future conversation. Anything to add now?
+
+DAF: XLIFF is a good topic for roundtrip feature discussions.
+
+ECH: Component test suite. Should we continue this one?
+
+SMY: Clarification about POC and implementation. Should we aim to include one for us? Should this be a deliverable?
+
+APP: Are we going to talk or code something?
+
+RCA: We are here from different areas APP. We should have a final implementation to be our test field. The roadmap for this implementation can become a topic for the next meeting. We should move forward with the other topics.
+
+DAF: To summarize, a number of POC is a success criteria, but not developed by the working group. Should be developed by others. But the conformance test suite is in our scope and we should have this as a deliverable.
+
+SMY: Agrees. Thanks for the clarification.
+
+ECH: Next is RCA.
+
+RCA: SMY asked for notes from SMY.
+
+SMY: merge 4 and 5, change language to more relatable to loc roundtrip. Keep XLIFF out of goals for now. Next is to add a conformance test suite to the deliverables. One action item for the group is to capture our thoughts about backward compatibility- but to exclude from the document for now, only add later if this makes sense.
+
+MIH: Reminder about date and number formats to be added.
+
+SMY: Is it a goal or a feature?
+
+MIH: Should be a separate bullet point. SMY agrees.
+
+SMY: It should be part of goals, not deliverables.
+
+RCA: We have to make changes to this document. Maybe we dont need to wait for the next meeting to merge changes to this document. We should actively review before the next meeting and have everything ready in Git.
+
+ECH: I agree. Think since SMY has the doc and has the list of changes, should we make a vote now? Then wait for Git changes -instead of discussing the changes next meeting.
+
+SMY: We could do something in between. Not too many changes planned for the doc, but we should try and do approval in Git- if no one complains before the end of May.
+
+DAF: Agree with SMY. We should use this monthly meeting to make this decision. 
+
+ECH: Agree with SMY and DAF.
+
+DAF: Use factoids instead of things as suggested by MIH. Terminology.
+
+MIH: Agree if this is the terminology. ‘Things’ is not an industry standard.
+
+DAF: Think they’re called factoids. 
+
+MIH: ‘Formattables’ maybe?
+
+DAF: Formattbales is fine with me if people don’t recognize factoids as an industry term..
+
+ECH: Consensus agreed with SMY PR with agreed changes. And we agree with the possibility to disagree by the end of May.
+
+DAF: The goals PR will be in “call for dissent” until the end of month.. 
+
+SMY: To update PR by Wednesday so people have time to discuss before the end of month.
+
+RCA: This PR will become input for prioritization of scope and next parts of our roadmap. We should try by email to prepare the next meeting in advance.
+
+ECH: We are good with goals and non-goals! We have 5m left and 2 agenda topics. How do we want to spend them?
+
+MIH: about mesageformat, people should check PR and discuss next time. 
+
+ECH: Ok multiple reasons to review PR. So the next item we can talk about is compatibility for design principles. 
+
+RCA: Next week is chair meeting. Today was a good step for the next chair meeting and prioritizing the next steps. 
+
+### Why MessageFormat needs a successor#49
+https://github.com/unicode-org/message-format-wg/issues/49
+
+This topic was moved for the next meeting 
+
+### Review Terminology #80
+https://github.com/unicode-org/message-format-wg/pull/80
+
+This topic was moved for the next meeting