On May 29, 2012, at 23:45 , Erik Corry wrote: > 2012/5/30 Norbert Lindenberg <[email protected]>: >> This is for the Language Specification, not the Internationalization API >> Specification. >> >> The assumptions are in the Language Specification, so they have to be >> addressed there. >> >> A normalization API can live in the Language Specification or in the >> Internationalization API. If we keep it simple (as this one function), then >> I think it can easily be added to String.prototype. More fine-grained >> functionality (like in ICU) would have to go into the Internationalization >> API (v2). The two are not mutually exclusive. > > Having read through the normalization spec I don't agree that it is > simple. I would suggest that this is more appropriately placed in the > internationalization API than in the core language.
I meant "simple" in terms of API surface. Implementing normalization is not simple, but you'd most likely rely on existing implementations such as ICU. > Since concatenating two long canonicalized strings to make a new > canonicalized string is much faster than first concatenating, then > renormalizing, perhaps a method should be provided for that combined > concat-giving-a-normalized-result operation. Such a method would be useful in an environment where strings are kept normalized all the time. However, keeping strings normalized requires attention to many more operations - the draft Character Model for the World Wide Web 1.0: Normalization [1] has a discussion. My impression is that not much software is designed to keep strings normalized throughout. Instead, you have to normalize them at the point where normalization actually matters: As part of or in preparation of text comparison operations. Norbert _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
