Internationalization: Additional values in API
ecmascript at norbertlindenberg.com
Tue Jun 26 15:22:00 PDT 2012
The TC 39 meeting on 2012-05-21 decided to allow implementations to recognize property values for which the specification prescribes an Error :
> - 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:
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  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.
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 . 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 , 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.
More information about the es-discuss