Provide structure in the registry for distinguishing types of options

[Mark Davis]

I think in the registry we need to be very clear about the following classes of effects that an option can have. (Of course, an option may do more than one of these)

• an option effectively supplies input in addition to the operand (eg, timezone, currency, ...)
• an option that modifies the formatting of the operand (eg, mix/max fractional digits)
• an option that modifies the selection of an operand (eg, also mix/max fractional digits)

We'll also have functions that transform the underlying value of an operand (we don't have any right now, but we will absolutely need that for offsets in order to support a core MF1.0 feature).

[Addison Phillips]

I don't understand your use of the term "operand" here. In our syntax, the term "operand" means the argument to a function:

{$operand :function option=value}

Do you mean "option"?

[Mark Davis]

Whoops, I'll fix that.

[Eemeli Aro]

You know, we could also consider separating out options that really are adding to the function's nominal input operand to also be operands. As in, allow for function expressions with more than one operand, such as:

Your purchases add up to {$sum $currency :number style=currency}

A marathon is {42.195 kilometer :number style=unit} long.

It is currently {$time |America/Chicago| :time} in Chicago.

The ABNF change for this would be relatively limited, with something like

value-expression = "{" [s]
                   (literal | variable)
                   [*(s literal | variable) s annotation]
                   *(s attribute)
                   [s] "}"

replacing the current literal-expression and variable-expression.

[Addison Phillips]

We could do that, but I think that goes against authoring simplicity as I no longer know what variable is being inserted.

In the case of the compound units, primary reason for "multiple operands" is the need to serialize the compound unit in some way. If one has values 2...n, then one can as easily assign them to options as to operands. And this keeps us out of the "find and match the argument" problem:

Your purchases add up to {$currency $sum :number style=currency}

A marathon is {kilometer 42.195 :number style=unit} long.

It is currently {|America/Chicago| $time :time} in Chicago.

You have a {|froot-loop| wildebeest extravaganza :string}.

Otherwise, I'm sure that (for example) Mihai will implement :number so that (in ICU4J) passing a com.ibm.icu.util.CurrencyAmount formats the getNumber() amount using the option currency set to getCurrency().getCurrencyCode() and, if not overridden by a style option, sets style=currency to boot.

[Tim Chevalier]

For clarity, I would suggest not using the word "effects", since MF functions don't have effects that are observable across different calls (or rather, if they do, that's not behavior the spec can depend on.)

That being said, this would be helpful for addressing #515 . You could think of this as a "data model" for runtime values, not just for messages.