Our exploration of data model ramifications led our Work Group to a strongly visible realization on challenges and tradeoffs around nested vs top level selectors.
The main arguments for disallowing nested selectors seem to be around complexity of such feature, and interoperability with existing localization tooling and vendor ecosystems.
The main arguments for allowing nested selectors seem to be around flexibility, support for complex scenarios and future-opportunities.
Mihai and I brainstormed how to move forward with recognition of that status.
Mihai wrote about avenues forward here: #103 (comment)
From my understanding (2) is what Mihai sides with, while (3) is where I see myself.
From this brainstorm came the following suggestion:
We (Mihai and Zibi) suggest forming an informal sub-group of MessageFormat 2.0 Work Group devoted to the exploration of a Nested Selection data model on top of the work performed by MF2.0 WG.
Such sub-group would be tasked with continuous monitoring of the work the main Work Group is doing for easy inclusion of the nested selectors.
The group would in result validate two hypothesis:
- Algorithmic conversion from nested to top level is possible and doesn’t bring limitations that would make such conversion lossy
- The output of MF2.0 Work Group can be extended to support nested selectors (in other words, no data model, API or syntax decision implicitly blocked nested selectors to be possible to be added)
In particular (2) is crucial here. The sub group would inform the MF2.0 WG on the consequences of the various decisions on ability to add nested selection. If the sub-group were to come to the main Work Group and notify us on such consequence, MF2.0 WG would still be free to make such a decision, but it would be an informed decision, rather than implicit lock-in.
If successful, the result of the sub-group work would be:
- A set of tools, APIs, data model, and syntax that extends MF 2.0 output to support nested selection
- Recommendation on auxiliary features and facets of features that would be valuable for nested selectors (meta information, syntax decisions, format algorithms etc.)
- If the WG will over time decide that nested selection is the right call, the sub-group’s work should make such extension smooth
- Alternatively, as the WG work progresses, the sub-group may come to main WG with a conclusion that nested selectors are no longer necessary as all the needs of nested selectors stakeholders have been met with the feature set of MF 2.0 proposal
- Finally, if we release MF2.0 without nested selection, but later the industry were to eventually decide to add nested selection, it would be MF 2.1, rather than MF 3.0 level of change.
In all scenarios, the nested selector sub-group would inform the main Work Group and secure the future extension for MF based on the perceived need, and validate hypotheses around it.
In practice, it would free the main Work Group to rely on the sub group to prevent unexpectedly blocking ourselves from being able to add nested selectors, while allowing the work to result in something that can easily be extended to support nested selection if the claim strengthens over time, or not, if the claim weakens.
How does it sound to you?
Our exploration of data model ramifications led our Work Group to a strongly visible realization on challenges and tradeoffs around nested vs top level selectors.
The main arguments for disallowing nested selectors seem to be around complexity of such feature, and interoperability with existing localization tooling and vendor ecosystems.
The main arguments for allowing nested selectors seem to be around flexibility, support for complex scenarios and future-opportunities.
Mihai and I brainstormed how to move forward with recognition of that status.
Mihai wrote about avenues forward here: #103 (comment)
From my understanding (2) is what Mihai sides with, while (3) is where I see myself.
From this brainstorm came the following suggestion:
We (Mihai and Zibi) suggest forming an informal sub-group of MessageFormat 2.0 Work Group devoted to the exploration of a Nested Selection data model on top of the work performed by MF2.0 WG.
Such sub-group would be tasked with continuous monitoring of the work the main Work Group is doing for easy inclusion of the nested selectors.
The group would in result validate two hypothesis:
In particular (2) is crucial here. The sub group would inform the MF2.0 WG on the consequences of the various decisions on ability to add nested selection. If the sub-group were to come to the main Work Group and notify us on such consequence, MF2.0 WG would still be free to make such a decision, but it would be an informed decision, rather than implicit lock-in.
If successful, the result of the sub-group work would be:
In all scenarios, the nested selector sub-group would inform the main Work Group and secure the future extension for MF based on the perceived need, and validate hypotheses around it.
In practice, it would free the main Work Group to rely on the sub group to prevent unexpectedly blocking ourselves from being able to add nested selectors, while allowing the work to result in something that can easily be extended to support nested selection if the claim strengthens over time, or not, if the claim weakens.
How does it sound to you?