W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Tue, 31 May 2011 18:49:29 -0400
Message-ID: <BANLkTi=HmHmr6QsX3zp68OVzd=TkHcyZdA@mail.gmail.com>
To: Pablo Castro <Pablo.Castro@microsoft.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Keean Schupke <keean@fry-it.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, May 31, 2011 at 6:39 PM, Pablo Castro
<Pablo.Castro@microsoft.com> wrote:
> 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.

I'm not sure I understand you.  My personal opinion is that there
should be no undefined behavior here.  If authors are allowed to pass
collation identifiers, the spec needs to say exactly how they're to be
interpreted, so the same identifier passed to two different browsers
will result in the same collation, i.e., the same strings need to sort
the same cross-browser.  Having only binary collation is better than
having non-binary collations but not defining them, IMO.

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

I'm okay with supporting only binary to start with.
Received on Tuesday, 31 May 2011 22:50:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:32 UTC