Currency and unit conformance

[aphillips]

Fixes #1009

Makes currency codes case-insensitive more clearly. We used a squidgy "SHOULD" before in spite of the ABNF provided.

Make units either CLDR identifiers or impl-defined types (SHOULD->MUST).

This is consistent with the stability policy (no new error is specified, no valid message becomes invalid, and :unit is DRAFT)

[eemeli]

This leaves it unclear what the resolved value is. Could we be more explicit?

Suggested change

	Currency codes are case-insensitive.
	The resolved `currency` value is normalized to upper-case.

[aphillips]

As a reminder, even ASCII letters have locale-sensitive case folding exceptions (Turkic languages).

Do we need to specify that the resolved value is uppercased? Mostly we treat the operands as immutable. We don't have to require that implementations perform the case fold operation. It's a good idea to do it to save later processing, but we can't really test it at the MF level except to say that a value with usd is as functional as one with USD.

[eemeli]

I think we should specify the casing, so that it's clear in a message like

.input {$n :currency currency=Usd}
{{{$n :foo:bar}}}

what currency value the :foo:bar function handler will see.

Suggested change

	Currency codes are case-insensitive.
	The resolved `currency` value is locale-insensitively normalized to upper-case.

[aphillips]

I have a variety of quibbles with the suggestion, starting with not using the defined term resolved value. Also, we allow implementation-defined (currency) types in this option also. Since the literals must be ASCII letters, we can use Unicode's casefold algorithm. Perhaps:

Suggested change

	Currency codes are case-insensitive.
	Currency codes are case-insensitive.
	If the value of the `currency` _option_ is a _literal_, the _resolved value_ MUST be case-folded to uppercase.

[eemeli]

Why limit the case-folding to literal values only? Why should the resolved value be different for $a vs $b?

.local $cc = {eur}
.input {$a :currency currency=eur}
.input {$b :currency currency=$cc}
...

[aphillips]

The value would have been resolved before reaching the function. So it is either resolved as a literal or as an implementation-defined type. We can't uppercase a Currency object, but we can on a literal. Note that your examples are in the MF processor space, but this directive is inside the function handler.

[eemeli]

We don't currently have any place in the spec that defines specific behaviour based on whether a value originates from a literal, and I would very much prefer not adding anything like that. The restriction on :number select makes sense and is only about the immediate option value in part to avoid needing to track the origins of variable values like this.

Given that we say that

The resolved value of a text or a literal contains the character sequence of the text or literal after any character escape has been converted to the escaped character.

The definition here ought to limit its impact not on whether the option's resolved value came from a literal, but on whethe or not it contains a character sequence.