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/ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
