I also want to note that some of the historic casing changes that Ken mentioned were precisely to allow for compatibility. The technical committee did a thorough review of all the characters that had uppercase forms but not lower case, to see which could possibly need a lowercase form added in the future. Those were then added, so that casing could be stabilized. The consortium and ISO/IEC SC2/WG2 committed to adding complete case pairs where necessary in the future to preserve that stability.
<br><br>Mark<br><br><div class="gmail_quote">On Dec 21, 2007 5:36 PM, Kenneth Whistler <<a href="mailto:kenw@sybase.com">kenw@sybase.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Patrik,<br><br>To perhaps allay some of the concerns you raised on the 16th<br>about property stability issues, I have run the table<br>derivation suggested in the contribution "Table Derivation"<br>posted earlier today by Mark and myself, against the
<br>public data files posted for all versions of Unicode<br>from Version 3.2 to Unicode 5.0 (and the beta data files<br>currently public for the as-yet-unreleased Unicode 5.1),<br>and pushed up the set of resulting derived property definition
<br>files to my public directory on the Unicode server:<br><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Always-3.2.0.txt" target="_blank">http://www.unicode.org/~whistler/idna/IDN_Always-3.2.0.txt</a><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Always-4.0.0.txt" target="_blank">
http://www.unicode.org/~whistler/idna/IDN_Always-4.0.0.txt</a><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Always-4.0.1.txt" target="_blank">http://www.unicode.org/~whistler/idna/IDN_Always-4.0.1.txt</a><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Always-4.1.0.txt" target="_blank">
http://www.unicode.org/~whistler/idna/IDN_Always-4.1.0.txt</a><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Always-5.0.0.txt" target="_blank">http://www.unicode.org/~whistler/idna/IDN_Always-5.0.0.txt</a><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Always-5.1.0.txt" target="_blank">
http://www.unicode.org/~whistler/idna/IDN_Always-5.1.0.txt</a><br><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Never-3.2.0.txt" target="_blank">http://www.unicode.org/~whistler/idna/IDN_Never-3.2.0.txt</a><br>
<a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Never-4.0.0.txt" target="_blank">http://www.unicode.org/~whistler/idna/IDN_Never-4.0.0.txt</a><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Never-4.0.1.txt" target="_blank">
http://www.unicode.org/~whistler/idna/IDN_Never-4.0.1.txt</a><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Never-4.1.0.txt" target="_blank">http://www.unicode.org/~whistler/idna/IDN_Never-4.1.0.txt</a><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Never-5.0.0.txt" target="_blank">
http://www.unicode.org/~whistler/idna/IDN_Never-5.0.0.txt</a><br><a href="http://www.unicode.org/%7Ewhistler/idna/IDN_Never-5.1.0.txt" target="_blank">http://www.unicode.org/~whistler/idna/IDN_Never-5.1.0.txt</a><br><br>Those are all diffable plain text files, in the same general
<br>format as used for other Unicode property files.<br><br>If you examine them carefully, you will discover that they<br>exhibit the very kind of cross-version stability that you<br>and others on the idna-update list have been concerned
<br>about, namely:<br><br> 1. Once a character is classed as NEVER, it does not<br> change that status in any later version of Unicode.<br><br> 2. Once a character is classed as ALWAYS, it does not<br> change that status in any later version of Unicode.
<br><br>To obtain this result for updating from Unicode 5.0<br>to Unicode 5.1, nothing at all is required in the way<br>of adjusting what Mark and I suggested for the table<br>derivation.<br><br>To make this work *retroactively* from Unicode
5.0 all<br>the way back to Unicode 3.2, it is necessary to add a<br>small number of characters to the exception_NEVER_list<br>that Mark and I discussed, because of a few casing changes<br>that happened as of Unicode 4.0 and a few other stray
<br>category changes. That list is very small, impacts<br>unimportant characters only -- and I'd be glad to share<br>the exact details if you are interested.<br><br>The point, however, is that starting with a carefully
<br>planned out table definition from the beginning, not only<br>is it possible to maintain complete backwards compatibility<br>for the NEVER and ALWAYS classes for IDN from<br>Unicode 5.0 and moving forward -- one can even set things
<br>up so as to guarantee retroactive backwards compatibility<br>for those classes all the way back to Unicode 3.2.<br><br>While we may obviously still want to discuss the details<br>and may differ in our opinions about the exact list of
<br>scripts that belong in the Historic_Scripts category<br>or the exact small list of characters that should<br>(like MIDDLE DOT) be in the exception_ALWAYS_list, and<br>so forth, I think that the above posted files should serve
<br>as an existence proof that it is possible to define the<br>derivation of this table in such a way as to guarantee<br>backwards compatibility of the property used by IDNA between<br>versions of Unicode.<br><br>Regards,
<br><br>--Ken<br><br>_______________________________________________<br>Idna-update mailing list<br><a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br><a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">
http://www.alvestrand.no/mailman/listinfo/idna-update</a><br></blockquote></div><br><br clear="all"><br>-- <br>Mark