In the syntax, function names are restricted to name rather than nmtoken, so not all NMTOKEN values can be valid here. Also, ensuring that function definitions map 1:1 to identifiers seems pretty reasonable?

The ID type is also subject to a validity constraint about there only being one element of the given name in the XML document: https://www.w3.org/TR/xml/#id.

I wasn't sure if we wanted to be this strict. Perhaps it's OK to have functions named the same as regex patterns? Or to have two function definitions with the same name? That's why I went for name and NMTOKEN.

Looking at the examples and considering usage in particular for contextual help (e.g. IntelliSense), I would think that we'd like to at least allow for descriptions to attach not just to <function>, but effectively all elements within them?

From the examples, I gather that the title attributes of <input> and <param> are likely meant to feed into such contextual help. What's the reason for preferring an element for this in one place and an attribute in another?

If we end up allowing for some nmtoken-ish values to be used unquoted as arguments (#364), it would be good to match that rule here.

I don't think #364 is related, actually. My intent here was to allow specifying either an enumeration of nmtokens or a regex to validate arguments that are MF2 literals. This seems orthogonal to whether these literals are quoted or not?

I meant that if #364 lands, then nearly all NMTOKEN values may be used without quoting, except for the ones that start with : and -. Given that, it might be appropriate to leave those out of the values that are definable by values rather than pattern.

I don't think we can enforce such restriction in the DTD alone. LDML does it by extending DTD with annotations: https://unicode.org/reports/tr35/#57-dtd-annotations.

Given that developers and translators will both be working with MF2, it might be clearer to use translate rather than readonly to communicate the intent of this attribute.

As a related question, shouldn't this also be available for <input>?

In general, I'm not fond of true being the default value. I think I'd prefer to name these attributes such that their lack is equal to false.

Re. readonly/translate for <input> -- good point. I think I'll drop the ability to define more than one <input> element per signature, then.

Re. readonly/translate for <input> -- good point. I think I'll drop the ability to define more than one <input> element per signature, then.

Done in 831a9cd.

Is this meant to be a building block for markup support? This attribute does not appear to be documented or explained.

This and the next bullet point are also hard to understand with "matching functions" and "formatting functions" being undefined terms.

Likewise, it might be useful to add "calling a formatting function in a selector context" and "calling a matching function in a placeholder context" to the list of possible errors in formatting.md. Depending on how I read the "Unknown Function errors" section, maybe that's already implicit, but since users would probably find a "function called in wrong context" error more helpful than an "undefined function" error, it's probably better to be explicit.

You're right, let's be explicit about this. I'd prefer to leave this out of this PR, however, because I think that we will first need to decide whether it's allowed to match on a function-less expression (i.e. match {$foo} instead of match {$foo :func}).

Filed #409 to discuss this further.

Is a regex enough to validate inputs or option values? For example, the second example on slide 13 here suggests that a formatting function could take some structured data as an argument.

I don't know yet how to validate runtime types. I'm suggesting to use regexes to validate literal values. Let's discuss what sort of type validation is even possible for some implementations.

Filed #407 about regexes and #408 about runtime types.

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.

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

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?

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 assume this title (and others such as the one on line 24) are meant to be human readable descriptions of the function/input/parameter? If so, it's bad practice to make them an attribute--because they can't easily be localized that way. It's better to make subsidiary elements to contain natural language text. The title fields don't appear to be necessary to the functionality in any case.

I'll remove title for now and we can discuss human-readable metadata separately.

Filed #405 to discuss this further.

There is nothing about types here. Strongly typed languages need some way to express this?

Not sure that "currency" is a good example here

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.