Registry information for minimizing runtime errors

[macchiati]

There are many environments where it is important to minimize* the possibility of runtime errors when formatting messages. I think we can do that for an important class of Selectors and Functions if we provide for more information in the registry. The following is still pretty rough, but it is what I'm trying to get at.

A Selector is well-behaved when all of the following conditions are met:

1. It declares a domain of variant keys, (eg "high", "medium", "low"; or integers; or any-string) in the registry.
2. For any set of modifiers it will return true for at least one element in that domain, and will return true or false for all others (without error).
3. It will always return true for *, with any set of modifiers.

A Function is well-behaved when all of the following conditions are met:

1. It declares a domain of variant keys (eg "high", "medium", "low"; or integers; or any-string) in the registry.
2. For any set of modifiers it will return a string for each element in that domain. (without error)

A message format is well-behaved when all of the following conditions are met:

1. It is syntactically correct.
2. All of its Selectors and Functions are well-behaved.

Inputs to a message format are complete when there is a value for each one of them that is used by a Selector (or Function) in the message, and that value is in the domain of that Selector (or Function).

Take the following message:

match {$personCount :number} {$venue :string}
when 1 * {There is a person at {$venue}}
when other * {There are {$personCount} people at {$venue}}

1. The following inputs are complete
   $personCount == 1
   $venue == "Paris"

2. The following inputs are not complete ($venue has no value)
   $personCount == 1

3. The following inputs are not complete ($personCount is not a number)
   $personCount == "fish"
   $venue == "Paris"

Well-behaved messages will not produce errors when their inputs are complete. This does not, of course, include extraordinary conditions such as out-of-memory.

Implementations of all standard registered Selectors and Functions must be well-behaved. Custom Selectors and Functions might not be.

[aphillips]

This appears to be both a request about metadata in the function registry and something that would influence the formatting part of the specification, hence the labels.

[aphillips]

@macchiati I don't know what to do with this issue, by which I mean: it is not specifically actionable.

The registry portion of the spec attempts to provide for input validation as well as defining aspects of the output. Elsewhere there is discussion about how to, e.g. incorporate CLDR data (such as PluralRules) in the description of selectors.

I'd like to close this issue and ask that you file specific issues against specific portions of the spec or, failing that, provide a design doc if you think something is needed which is not currently present.