That works (for now). Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* **
On Wed, Sep 5, 2012 at 11:04 AM, Norbert Lindenberg < [email protected]> wrote: > It was too weak indeed - I added the requirement that normalization is > turned on by default. > > Norbert > > > On Sep 4, 2012, at 13:23 , Mark Davis ☕ wrote: > > > In view of the schedule, I suggest that we make your first, minimal > change right now, and plan to correct it along one of the other lines in > the next edition. > > > > #1 is much weaker than we want, so we should correct it, but we can do > that in edition 2. > > > > Mark > > > > — Il meglio è l’inimico del bene — > > > > > > > > On Tue, Sep 4, 2012 at 12:35 PM, Norbert Lindenberg < > [email protected]> wrote: > > 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 < > [email protected]> 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 < > [email protected]> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
