Lars Kristan <[EMAIL PROTECTED]> wrote: > Suppose ISO 8859-8 is ever upgraded (even if not likely, but - for the sake > of argument). One might say that it would be bad to change an existing > definition in the table e.g. for 0xBF from 0x2DBF to 0x20AC. But how is that > worse from changing it from <undefined> to 0x20AC ? > I think it is actually better, since you can never guess what will be > implemented for <undefined>. "Throw and exception" is what I keep seeing in > these discussions. Who will catch it? The secretary on the third floor?
"Defining" undefined code points to be something they aren't is not a Good Thing. Even if ISO 8859-8 were updated at some time in the future, with new code points being added, the old data that was created with the old 8859-8 would still contain invalid data. > If mapping for undefined values would be 0xhh -> 0x2Dhh, then there would be > a consistent definition of what to do if somebody wants to do something else > than throw things out the window. Consequentially, there would be a better > chance of being able to repair inadvertently processed data at some later > time. It's not repairable, because it contained garbage. -Doug Ewell Fullerton, California
