Internationalization: Additional values in API

[Mark Davis ☕]

I tend to agree with your proposal.

Some caveats below.


------------------------------
Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**



On Tue, Jun 26, 2012 at 3:22 PM, Norbert Lindenberg <
ecmascript at norbertlindenberg.com> wrote:

> 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 ones that are integers it would seem odd to accept others.


> - 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".
>

I agree with your reasoning below, but would I would rather use the CLDR
values in http://unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml,
since they are based on the TZDB but mroe stable. Either just names or
names + aliases.


> - 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.
>

I'm a bit hesitant about the screening, since it may take a while (looking
at history) between updates, unless there is a lighter-weight mechanism.


>
> - 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/
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120626/09c4e782/attachment-0001.html>