Table issues (Part 2)

[Mark Davis]

Let me try to be more explicit about how this would be expressed in the
text.

("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.)

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.

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.)

1. Change all references from 5.0 to 5.1. (Unicode 5.1 will be out before
this is done.)

2. Change the text in section 1.

The mechanisms described here allow
determination of the value of the property for future versions of
Unicode (including characters added after Unicode 5.0). It should be
suitable for newer revisions of Unicode, as long as the Unicode
properties on which it is based remain stable.
=>
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.

3. Add new sections:

2.2.6. Category L - Backwards Compatibility ALWAYS

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.

2.2.7. Category M - Backwards Compatibility NEVER

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.

4. Change in section 3:

   First the special cases.  If there is a match, do not go to the
   second phase.
   o  If the codepoint is in Category G (Section 2.2.1), the value is
      ALWAYS.

=>

   First the special cases.  If there is a match, do not go to the
   second phase.
   o  If the code point is in Category L (Section 2.2.6) or Category
      G (Section 2.2.1), the value is ALWAYS.
   o  If the codepoint is in Category M (Section 2.2.7), the value is
      NEVER.



Mark

On Dec 5, 2007 9:16 AM, Patrik Fältström <patrik at frobbit.se> wrote:

>
> On 4 dec 2007, at 22.17, Mark Davis wrote:
>
> > By doing this, we'd guarantee
> > that all characters that were {IDN=Always} in a previous version are
> > {IDN=Always} in the current version;
>
> But the change of one of the properties that you might change happens
> because of a reason (error in the definition, new findings etc). This
> imply that the derived property over time will diverge from the real
> derived property over time. Right?
>
> I.e. {derived-property-according-to-5.1} might be a superset of
> {derived-property-according-to-5.2}, i.e. if you do the calculations
> on 5.1 you get a larger set than if you do the calculations on 5.2?
>
>    Patrik
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>



-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20071205/edbbf75b/attachment.html