Let me try to be more explicit about how this would be expressed in the text.<br><br>("Stable" is not really the right term, since characters are added over time. What we are really concerned with is *backwards compatible* property
values: if an assigned character has the property value in Unicode Version N,
it will also do so in Version N+1.)<br><br>It is perfectly possible to have a backwards-compatible
*derived* property value, _even if_ the properties it is derived from
are not themselves backwards compatible. We have done this before in Unicode; it is one of the many aspects of working with 100,000 characters that we've had to develop over the 20 years of Unicode work.<br><br>Here is some suggested text that would make your IDN property
backwards-compatible. (Note that I have been out of town, and haven't
had a chance to review the rest of the document.)<br><br>1. Change all references from
5.0 to 5.1. (Unicode 5.1 will be out before this is done.)<br><br>2. Change the text in section 1.<br><br><div style="margin-left: 40px;"> The mechanisms described here allow<br> determination of the value of the property for future versions of
<br> Unicode (including characters added after Unicode 5.0). It should be<br> suitable for newer revisions of Unicode, as long as the Unicode<br> properties on which it is based remain stable.<br>=><br>
The mechanisms described here allow determination of the value of the
property for Unicode 5.1 and all subsequent versions of Unicode. The
values of ALWAYS and NEVER, in particular, are guaranteed to be
backwards compatible -- once a character has those values in any
version of Unicode, it will always have those values in all future
versions of Unicode. This is true even though some of the properties on
which those values are based may change between versions of Unicode.
<br></div><br>3. Add new sections:<br><br><div style="margin-left: 40px;">2.2.6. Category L - Backwards Compatibility ALWAYS<br><br>This
category consists of code points in Unicode that were assigned to
ALWAYS by applying the calculation rules in Section 3 to any previous
version of Unicode extending back to Unicode version 5.1. That is, if
the current version of Unicode were 7.0, and character X had been
determined to be ALWAYS according to an application of the rules in,
say, Unicode 6.1, then it has a backward-compatibility value of ALWAYS.
<br><br>2.2.7. Category M - Backwards Compatibility NEVER<br>
<br>
This category consists of code points in Unicode that were assigned to
NEVER by applying the calculation rules in Section 3 to any previous
version of Unicode extending back to Unicode version 5.1. That is, if
the current version of Unicode were 7.0, and character X had been
determined to be NEVER according to an application of the rules in,
say, Unicode 6.1, then it has a backward-compatibility value of NEVER.<br></div><br>4. Change in section 3:<br><br><pre> First the special cases. If there is a match, do not go to the<br> second phase.<br> o If the codepoint is in Category G (Section
2.2.1), the value is<br> ALWAYS.<br><br>=><br><br> First the special cases. If there is a match, do not go to the<br> second phase.<br> o If the code point is in Category L (Section 2.2.6) or Category <br>
G (Section 2.2.1), the value is ALWAYS.<br> o If the codepoint is in Category M (Section 2.2.7), the value is<br> NEVER.<br></pre><br><br>Mark<br><br><div class="gmail_quote">On Dec 5, 2007 9:16 AM, Patrik Fältström <
<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</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>
On 4 dec 2007, at 22.17, Mark Davis wrote:<br><br>> By doing this, we'd guarantee<br>> that all characters that were {IDN=Always} in a previous version are<br>> {IDN=Always} in the current version;<br><br></div>
But the change of one of the properties that you might change happens<br>because of a reason (error in the definition, new findings etc). This<br>imply that the derived property over time will diverge from the real<br>derived property over time. Right?
<br><br>I.e. {derived-property-according-to-5.1} might be a superset of<br>{derived-property-according-to-5.2}, i.e. if you do the calculations<br>on 5.1 you get a larger set than if you do the calculations on 5.2?<br><font color="#888888">
<br> Patrik<br></font><div><div></div><div class="Wj3C7c"><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></div></div></blockquote></div><br><br clear="all"><br>-- <br>Mark