Re: Biblical Hebrew (Was: Major Defect in Combining Classes of Tibetan Vowels)

From: Karljürgen Feuerherm (
Date: Fri Jun 27 2003 - 09:23:08 EDT

  • Next message: Karljürgen Feuerherm: "Re: Biblical Hebrew (Was: Major Defect in Combining Classes of Tibetan Vowels)"

    > At 04:22 -0500 2003-06-27, 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

    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?


    This archive was generated by hypermail 2.1.5 : Fri Jun 27 2003 - 10:05:27 EDT