RE: [IndexedDB] Closing on bug 9903 (collations)


-----Original Message-----
From: simetrical@gmail.com [mailto:simetrical@gmail.com] On Behalf Of Aryeh Gregor
Sent: Friday, May 06, 2011 10:05 AM


>> On Fri, May 6, 2011 at 5:18 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> > Based on that, my conclusion is that we should go with what Pablo is
>> > proposing. And I think we should do it for v1.
>>
>> If I understand correctly, Pablo's proposal is that the author be
>> allowed to specify a locale, and the browser can collate in some
>> undefined way based on that locale.  That sounds like a really bad
>> idea for interop.  If non-binary collation is supported in a first
>> version, it should be either

No, that was poor wording on my part, I keep using "locale" in the wrong context. I meant to have the API take a proper collation identifier. The identifier can be as specific as the caller wants it to be. The implementation could choose to not honor some specific detail if it can't handle it (to the extent that doing so is allowed by the specification of collation names), or fail because it considers that not handling a particular aspect of the collation identifier would severely deviate from the caller's expectations.

>> 1) Two choices, binary or UCA 6.0.0.  (AFAIK, UCA gives fairly good
>> results for most languages even without tailoring, so it might be just
>> fine for v1.  It's vastly better than binary, for sure.)

Given the amount of debate on this, could we at least agree that we can do binary for v1? We can then have an open item for v2 on taking collation names and sort according to UCA or taking callbacks and such.

>> 2) In addition to binary and UCA 6.0.0, allow UCA 6.0.0 tailored by
>> any of the locales defined by CLDR 1.9.1.
>>
>> There also needs to be some thought put into how to handle version
>> updates, since browsers cannot update their UCA or CLDR implementation
>> without rebuilding all existing indexes that used it (unless they keep
>> the old implementation forever).  It might be that browsers should
>> just stick to a fixed version for the time being (like 6.0.0 and
>> 1.9.1), and we might decide that no further APIs are needed now to
>> accommodate possible future switches, but at least some thought needs
>> to be given to it.

I wonder if the API (independently of when we get to this) should include the version either as part of the collation identifier or as a separate argument. This would allow UAs to support a version or two for a while, and then phase them out as they fall out of use in favor of newer ones.

>> On consideration, I don't think user-specified sortkey functions are
>> necessary at this stage.  If collations are to be identified by
>> strings for now, we could always overload the value to accept a
>> function at some later date if we wanted to support that.  So I
>> wouldn't worry about that further.

I agree.

-pablo

Received on Tuesday, 31 May 2011 22:40:10 UTC