Table-building

[Patrik Fältström]

On 1 feb 2007, at 06.50, Harald Tveit Alvestrand wrote:

> --On 31. januar 2007 18:01 -0800 Mark Davis <mark.davis at icu- 
> project.org> wrote:
>
>> I think this does expose an issue that needs discussion. There are  
>> two
>> types of stability that could be guaranteed.
>>
>> 1. Once a character is encoded, the property value (true or false)  
>> MUST
>> never change.
>> 2. Once a character is given the property value of true, its value  
>> MUST
>> never change to false. An encoded character SHOULD not change from  
>> false
>> to true, unless a strong case can be made for it.
>>
>> For both of them we have the key requirement for stability, that  
>> once a
>> string qualifies as being valid, it stays valid forever.
>>
>> However, #1 might be a bit too restrictive. If we currently say that
>> character X has the value false, but there is an issue if for some  
>> reason
>> we find out that that character is needed for some orthography of a
>> language in, say, the Congo. People who think that #2 is not  
>> sufficient
>> might present some scenarios where it could cause a problem (I can't
>> think of any myself).
>
> Well put.
>
> The discussion has exposed literally dozens of cases where the  
> answer to "should the property be true or false" is "We don't know  
> yet".
>
> It is clearly stupid of any registry to allow the registraition of  
> such characters, given that the property MAY end up false.
> It is equally stupid of any application developer to deny the  
> attempt to lookup such characters, given that the property MAY end  
> up true.
>
> I think that's what the "tri-state" tables are trying to express.

I completely agree. I think it is important that characters that have  
the property value FALSE MUST NOT change to TRUE either. I am nervous  
"...unless a strong case can be made for it" is to weak. The FALSE  
value must be possible to be used in applications.

So in reality we have four different situations:

- TRUE
- FALSE
- MAYBE (which in reality is "false for now, but might change to  
true, but also might not")
- Not assigned

    Patrik