Table-building

[Harald Tveit Alvestrand]

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

                         Harald