Seeing that the final draft of the spec is due today, here's a breakdown of possible changes around normalization in Collator:
1) Change the description of Intl.Collator.prototype.compare to say: "The method is required to return 0 when comparing Strings that are considered canonically equivalent by the Unicode standard, unless collator has a [[normalization]] internal property whose value is false." This is the smallest possible change to the spec that's needed to make its canonical equivalence and normalization requirements consistent, and I've made it. 2) Require support for the normalization property and the kk key. The way I phrased the spec in 1), this isn't necessary anymore, and we can make this change in the second edition if needed. 3) Add "locale" to the set of acceptable input values for the normalization property of options. Implementations that support the normalization property would use the selected locale's default for the "kk" key. The normalization property of the object returned by resolvedOptions remains a boolean. This change could be made today or in the second edition. If we make it in the second edition, implementations of the first edition would interpret "locale" as true because "locale" is truthy. The conformance clause does not allow implementations to add support for this value on their own. 4) Add "locale" to the set of acceptable values of the kk key of BCP 47. The Internationalization API would use this, if the normalization property of options is undefined, to map to the appropriate boolean value. This can't happen today, and I'm not sure it's really required. Turning off normalization is primarily an optimization and so should be under application control. Comments? Norbert On Sep 1, 2012, at 16:19 , Mark Davis ☕ wrote: > > Support for the normalization property in options and the kk key would > > become mandatory. > > The options that ICU offers are to observe full canonical equivalence: > • For all locales > • kk=true > • For key locales (where it is necessary); otherwise partial (FCD) > • kk=<not present> > • For no locales; always partial (FCD) > • kk=false > Your proposal looks reasonable, except I'm not sure how someone would use the > kk value to get #2. > > Mark > > — Il meglio è l’inimico del bene — > > > > On Fri, Aug 31, 2012 at 3:30 PM, Norbert Lindenberg > <ecmascr...@norbertlindenberg.com> wrote: > I think #2 is far more common for ECMAScript - typical use would be to > re-sort a list of a few dozen or at most a few hundred entries and then > redisplay that list. #1 might become more common though as JavaScript use on > the server progresses. > > So here's an alternative spec approach: > > - Leave the specification of String.prototype.localeCompare as is. That is, > if it's not based on Collator, canonical equivalence -> 0 is required. > > - For Collator.prototype.compare, require that canonical equivalence -> 0 > unless the client explicitly turns off normalization (i.e., normalization is > on by default, independent of locale). Support for the normalization property > in options and the kk key would become mandatory. > > Norbert > > > On Aug 31, 2012, at 10:12 , Mark Davis ☕ wrote: > > > I think we could go either way. It depends on the usage mode. > > • The case where performance is crucial is where you are comparing > > gazillions of strings, such as records in a database. > > • If the number of strings to be compared is relatively small, and/or > > there is enough overhead anyway, the performance win by turning off full > > normalization would be lost in the noise. > > So if #2 is the expected use case, we could require full normalization. > > > > > > Mark > > > > — Il meglio è l’inimico del bene — > > > > > > > > On Fri, Aug 31, 2012 at 9:56 AM, Norbert Lindenberg > > <ecmascr...@norbertlindenberg.com> wrote: > > The question for ECMAScript then is whether we should stick with "must do" > > (the current state of the specifications) or change to "must be able to do". > > > > The changes for "must be able to do" would be: > > > > - In the Language specification, remove the description of > > String.prototype.localeCompare, and require implementations to follow the > > Internationalization API specification at least for this method, or better > > provide the complete Internationalization API. That way, localeCompare > > acquires support for the normalization property in options, and the -kk- > > key in the Unicode locale extensions. > > > > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
