Description
With our current registry definition, each <function> may contain multiple <formatSignature> and <matchSignature> elements, each of which separately defines their inputs and options. I think this structure allows too much variation and is difficult to extend.
For context, let us consider a registry that extends our base registry by adding an option icu:skeleton to the :datetime formatter. What does that registry look like, and what changes are required to make that possible and easy to use?
First, this child registry needs some way of indicating which parent registry it's extending. One possibility is a new attribute with a URL value:
<registry extends="https://unicode.org/path/to/messageformat/registry.xml">Are there other alternatives? Is there some more natively XML-ish way to express this sort of parent-child relationship?
Next, we need a way to identify the parent registry's formatter definition to which we're adding the option. At the moment, as we allow for and use more than one <formatSignature> in <function name="datetime">, this is difficult. I can think of a couple of different solutions:
- Add a required unique
idon each<formatSignature>and use that to link the parent and child signatures. - Do not support having more than one
<formatSignature>and<matchSignature>in each<function>. - Drop the intermediate
<formatSignature>and<matchSignature>elements, and indicate otherwise whether the function supports formatting and matching, and which options affect either.
Are there other possibilities that could be considered? One additional required change here changing the <function name> to be a ID rather than an NMTOKEN.
My own preference would be the third one, because that would also solve another potential problem: Currently, we allow for each function option to have completely independent and different meanings in each <formatSignature> and <matchSignature>. So the permitted values for an option foo can change entirely depending on whether another option bar is set, and where in the message it's used. This is unnecessarily liberal.
Alternatively, we could take the approach used by <alias>, and add a supports=format|match|all attribute to <function> and <option>, with the latter being defined directly under <function>. This way, each option would only have a single definition that's independent of its position in the message.
If we choose either the second or third option, we should consider adding an attribute like conflicts or excludes on <option> to allow for the definition of mutually incompatible baskets of options.
To sketch out this possibility in more detail, here's what the registry.xml could look like if the changes from #560 are also incorporated: https://github.com/eemeli/message-format-wg/blob/extend-registry/spec/registry.xml
Finally, we need a definition of how the merge happens. Do we only support extending the whole <registry>, or also individual <function> and other elements? Do we support localization of the descriptions as an extension, or should that require a manual copy?