Would it be an error for an option to have both a required and a default attribute?

Since a finite enumeration can be expressed as a regex, I'm wondering if it would be simpler to only allow a regex? I can imagine a tool providing finite enumerations as syntactic sugar.

Hmm, interesting. I'm not opposed to removing values and keeping pattern as the only option. The reasons why I opted for both were:

• values allows the values to be specified inline (<match values="one other"/>) whereas pattern refers to a <pattern> element by id. I felt it was more convenient in particular for plural categories, cases and genders to be able to define them inline rather than define a regex for each possible combination.
• Some supplemental data in CLDR uses values="<enumeration>", too, e.g. https://github.com/unicode-org/cldr/blob/release-43/common/supplemental/grammaticalFeatures.xml, so it's easy to reuse this data as-is.

Do you feel strongly about this?

Generating autocompletion values for an editor is easy from an explicit list in values, but really hard from a regexp pattern. I'd much rather keep values even if only for that.

@stasm No, I don't feel strongly, and @eemeli has a good point, so I withdraw the question :)

Is it "one or more" or "zero or more"? The DTD implies that there can be zero <match> elements, as does the second signature for number in the example below.

I'm very curious about the locales attribute--curious in this case is a euphemism for "nervous about". I would prefer if functions were mostly locale neutral (I can declare, for example, a number format in any message in any locale).

We should have some way to define at least locale-dependent option and match values. For example, the registry should allow for a way to note that while the whole set of CLDR categories is zero one two few many other, a specific locale such as en only uses one other.

One alternative could be for <matchSignature> and <formatSignature> to be able to contain an <override locales="en fr it"> section.

For completeness of the example, my plan was to allow the overrides directly on the level of the matchSignature and formatSignature:

<function name="plural">
    <matchSignature locales="en">
        <input pattern="anyNumber"/>
        <option name="type" values="cardinal ordinal"/>
        <option .../>
        <match values="one other"/>                    ← English plurals
        <match pattern="anyNumber"/>
    </matchSignature>

    <matchSignature locales="pl">
        <input pattern="anyNumber"/>
        <option name="type" values="cardinal ordinal"/>
        <option .../>
        <match values="one few many other"/>           ← Polish plurals
        <match pattern="anyNumber"/>
    </formatSignature>
</function>

I am not a fan of this. I think that a plural selector should recognize all of the keywords and not depend on the registry to "allow" or "disallow" the enumerated values for a given locale (note that locales must be a "language range", otherwise you would need to list every possible language tag and is probably an extended language range, e.g. so that pl-PL matches pl-Latn-PL -- not that anyone would use that tag)

I think it is reasonable that (for example) the root locale message can contain keywords that do not fire for a specific locale but which fire in others, in case that message is used in one of those other locales. This is also why the * defaulting key exists (such as the case where an English-language resource with only one and * gets used in the pl locale).

In the case of plurals, CLDR provides the data about which keywords apply to which locale. In the case of some other formatter or selector that is not supplied by CLDR, the implementation should know what applies to each locale. If we want the registry to describe that relationship (for example to support exploding the matrix of keys in localization tools), I think I would prefer that it be separate from the signature, e.g.:

<function name="customPluralLikeSelector">
   <matchSignature>
      <input pattern="anyNumber"/>
      <option name="type" value="foo bar"/>
      <match value="zero one two few many other"/>
      <match pattern="anyNumber"/>
   </matchSignature>
   <validate comment="the naming is terrible and we wouldn't structure it exactly like this">
      <match type="values">
         <value lang="">one other</value>
         <value lang="pl">one few many other</value>
         <value lang="ja">other</value>
         <!-- etc. --->
      </match>
   </validate>

Oh, I think I like it!

Filed #410 to discuss this further.

I'm a little confused about why there's a case option for an adjective if this signature is only defined in locale "en".

English doesn't make it easy to build meaningful examples of grammatical features :) I'll try to come up with something better.

Yeah, I know :) I was just thinking the example could be from a different language, maybe.

The accord option doesn't have a pattern or an enumeration, which surprises me given lines 51-52 (which suggest to me that every option has one or the other).

Right, this is still WIP and underspec'ed. I'd like to continue the discussion about validating runtime values outside of this PR.

What happens if you write {You see {$color :adjective article=indefinite}}? Since none of the options in the example are required, it's unclear which of the two signatures for :adjective should be used. Or does it not matter because the idea is that :adjective has a single implementation for all signatures?