- From: Addison Phillips via GitHub <sysbot+gh@w3.org>
- Date: Fri, 06 Sep 2019 17:39:10 +0000
- To: public-i18n-archive@w3.org
Lots of specs "do the right thing", but the first problem is that there are choices you need to make in defining what "the right thing" is. Given what you are doing and the simplicity of the instructions provided, I think what you mean here goes beyond case sensitivity: the `cacheName` value is expected to be an identical sequence of Unicode code points to the `key`. What you should do is define the term 'matches' and then use it for string comparison. For an example of this, see HTML: https://html.spec.whatwg.org/multipage/infrastructure.html#case-sensitivity-and-string-comparison Which says: > Comparing two strings in a case-sensitive manner means comparing them exactly, code point for code point. > Except where otherwise stated, string comparisons must be performed in a case-sensitive manner. This presumes that: * `cacheName` and `key` do not include any character escapes and that they are normal DOMStrings. * You do not intend Unicode normalization to influence the matching (we recommend that you do not use Unicode normalization here) Our document [Charmod-Norm](https://www.w3.org/TR/charmod-norm) hopefully provides explanation in case you are curious why you might want to do something different. -- GitHub Notification of comment by aphillips Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/28#issuecomment-528946476 using your GitHub account
Received on Friday, 6 September 2019 17:39:11 UTC