From: Karljürgen Feuerherm (cuneiform@rogers.com)
Date: Fri Jun 27 2003 - 09:23:08 EDT
> At 04:22 -0500 2003-06-27, Peter_Constable@sil.org wrote:
>
> >I just have a hard time believing that 50 years from now our
> >grandchildren won't look back [...]
I am in complete agreement with the spirit of what Peter says, though
realistically, 50 years from now, this is likely to be all neither here nor
there... (?)
I can't address all the technical details of the issue(s) at hand, however,
from a point of view of computing systems generally speaking, I think the
following is true:
1. Everyone is more or less agreed that the present combining class rules as
they apply to BH contain mistakes. The clearly preferential way to deal with
mistakes in any technological/computing software environment is to FIX them.
Several people have expressed reasons why this can't be (practically) be
done--which mainly seem to stem from political concerns.
2. Consequently ANY OTHER solution than 'FIX the obvious mistake(s)' is a
kludge (contra Philippe's (?) recent comment). One *pays* for all kludges,
one way or the other. If one is going to do this clearly undesirable thing,
one had better face that, acknowledge it, and be prepared to live with it,
and not try to talk one's way out of it being a kludge.
3. In that case, the question is, which kludge will cause less damage in the
end? (Because kludges will ALWAYS cause some problem one hasn't forseen. It
is their nature, since they involve adding twists into an otherwise plain
approach and complicating the algorithms in ways that are mystifying even to
the experts, after a while.)
4. Creating a whole new set of characters whose combining classes can be
redefined from scratch 'correctly' would seem to be undesirable, for a host
of reasons: one can't justify duplicating existing characters (specially, if
I understand it correctly, in the ISO environment which doesn't have all
these other superset systems?), and to some extent, one (perhaps?) runs the
risk of duplicating the present mess yet again, if one makes another
mistake....
5. Inserting some kind of other character in the chain (perhaps even a
different one depending on the case, whether double vowels or metheg or
whatever--that is not the issue just now) is clearly a kludge too... but
then the sub-issue becomes whether to overload new semantics on existing
characters (e.g. ZWJ etc.) with the potential of adding exponentially more
twists in the system. Would it not be preferable, in that case, to create a
new character (with the appropriate attributes that I really can't comment
on) whose semantic is specific to addressing the current problem? New
(clean) rules would then have to be defined to cope with this. This keeps
the mess to a minimum.
Now, Q: I take it the combining classes are linked to the script, rather
than say to a dialect--e.g. one can't define BH as a separate dialect from
MH with its own set of rules? (I assume this is the case because otherwise
someone would have proposed it already.)
I REALLY think that option 1 should be beaten to death with a stick, then
beaten to death again, before settling for one of the others.
Hoping this didn't sound like a pointless diatribe but rather that taking a
step back from the details might help?
K
This archive was generated by hypermail 2.1.5 : Fri Jun 27 2003 - 10:05:27 EDT