Internationalization: Additional values in API

[Norbert Lindenberg]

The TC 39 meeting on 2012-05-21 decided to allow implementations to recognize property values for which the specification prescribes an Error [1]:

> - 2. Conformance
>    - What about already defined properties? Can we add new, implementation specific values, like v8Identical for collator sensitivity?
>    - We should throw if we don't recognise the value. You may recognise additional property values.

I'd like to propose a more restricted escape hatch, to be added to the existing allowances for additional objects, properties, and functions in the Conformance clause:

<spec>
In the following cases where the specification requires that a RangeError is thrown for unacceptable input values, implementations may define additional acceptable input values for which the RangeError is not thrown:
- The options property localeMatcher in all constructors and supportedLocalesOf methods.
- The options properties usage and sensitivity in the Collator constructor.
- The options properties style, currencyDisplay, minimumIntegerDigits, minimumFractionDigits, maximumFractionDigits, minimumSignificantDigits, and maximumSignificantDigits in the NumberFormat constructor.
- The options property timeZone in the DateTimeFormat constructor, provided that the additional acceptable input values are case-insensitive matches of Zone or Link identifiers in the IANA time zone database [2] and are canonicalized to Zone identifiers in the casing used in the database for DateTimeFormat.resolvedOptions().timeZone, except that "Etc/GMT" shall be canonicalized to "UTC".
- The options properties listed in table 3 in the DateTimeFormat constructor.
- The options property formatMatcher in the DateTimeFormat constructor.
</spec>


The above prevents additional values in the following cases:

- Input values that lead to TypeError exceptions. These are usually not meaningful extension points.

- Input values that are boolean. There just aren't additional meaningful boolean values.

- Language tags that are not structurally valid. Structural validity is a quite minimal requirement, and BCP 47 itself is very extensible. Allowing additional values in the Internationalization API would only create confusion.

- Currency codes that are not well-formed. Here as well, well-formedness is a quite minimal requirement, and ISO 4217 itself allows registration of any actual new currency codes. Allowing additional values in the Internationalization API would only create confusion.

- Additional keys and values from Unicode Technical Standard 35, Unicode Locale Data Markup Language [3]. UTS 35 defines several keys and values that we have agreed are not useful for the Internationalization API, so we should be able to screen new ones before they're added.

- NaN and +/- Infinity in DateTimeFormat.prototype.format. These just aren't meaningful time values.


The most unusual part of the proposed addition to the Conformance clause is the mini-specification for additional time zone identifiers. In the discussions on DateTimeFormat, we deferred defining support for a larger set of time zones because not all implementations are ready to support them. If we allow implementations to accept additional values, however, it's a pretty safe guess that several implementations will extend the set of supported time zones quickly, because applications need it, and it's also a pretty safe guess that they'll build their support around the IANA time zone IDs [2], and that the values would not be prefixed. There may however be inconsistencies around case significance and around canonicalization of the names in DateTimeFormat.prototype.resolvedOptions. In this situation, I think it would be better to standardize now which values may get accepted optionally and how they're processed.

Comments?

Regards,
Norbert


[1] https://mail.mozilla.org/pipermail/es-discuss/2012-May/022836.html
[2] http://www.iana.org/time-zones/
[3] http://unicode.org/reports/tr35/