<br><div class="gmail_quote">On Sat, Jul 12, 2008 at 11:38 AM, Paul Hoffman <<a href="mailto:phoffman@imc.org">phoffman@imc.org</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;">
<div class="Ih2E3d"><br>
<br>
</div>The "can be" works for me. Using "will be" makes it sound more like<br>
it is acceptable for TUC to make unacceptable changes.</blockquote><div><br>"unacceptable" is the wrong term here.<br><br>Paul, perhaps you missed an earlier discussion. The purpose of the BackwardCompatible category in the tables document is because the Unicode consortium must sometimes make changes to properties. The character properties are general, and for many or even most people it is more important for them to be as correct as possible than that they be stable. It is not always possible, especially with minority characters, to get the properties exactly right initially.<br>
<br>A grandfathering clause allows for both stability for those who need it, and correctness for others.<br><br>The consortium uses exactly the same mechanism in stabilizing its recommended definition of program identifiers (eg like those used in Java and other languages that allow for non-ASCII). Over the course of many Unicode versions, a handful of characters it total have been affected. For details, see <a href="http://www.unicode.org/reports/tr31/#Backward_Compatibility">http://www.unicode.org/reports/tr31/#Backward_Compatibility</a><br>
<br>While not by any means frequent or many, it is not unlikely that some characters will need to be added to BackwardCompatible in some future Unicode Version. So that event needs to be planned for, not ignored.<br><br>Whether or not any such changes are needed will be known in the beta phase of each Unicode release, which is months ahead of the release date. So we just need to make sure that whatever mechanism is used to update the BackwardCompatible list can be done in months (not years). My own preference would for this list to be hosted on IANA and subject to Expert Reviewers Committee, with requirements set by the RFC that all and only those characters necessary for backwards compatibility be added for each Unicode release. But if the RFC process could accommodate a few month turn-around (guaranteed), that would work also.<br>
<br>Mark<br></div></div><br>