Lars Kristan <lars.kristan@hermes.si> 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
This archive was generated by hypermail 2.1.2 : Sat Mar 16 2002 - 00:40:04 EST