ECMAScript collation question

[Mark Davis ☕]

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 <
ecmascript at norbertlindenberg.com> 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 <
> ecmascript at norbertlindenberg.com> 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 <
> 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/20120905/e0e17677/attachment-0001.html>