ECMAScript collation question

[Mark Davis ☕]

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

   1. For all locales
      - kk=true
   2. For key locales (where it is necessary); otherwise partial (FCD)
      - kk=<not present>
   3. 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 <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**



On Fri, Aug 31, 2012 at 3:30 PM, Norbert Lindenberg <
ecmascript at 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 <
> ecmascript at 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.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120901/fe496402/attachment.html>