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

From: Karljürgen Feuerherm (
Date: Fri Jun 27 2003 - 13:22:42 EDT

  • Next message: John Cowan: "Re: Biblical Hebrew (Was: Major Defect in Combining Classes of Tibetan Vowels)"

    John Cowan said on June 27, 2003 at 12:48 PM

    > Karljürgen Feuerherm scripsit:

    > > > > Several people have expressed reasons why this can't be
    (practically) be
    > > > > done--which mainly seem to stem from political concerns.
    > > >
    > > > All concerns involving human beings -- ho bios politikos -- are
    > > > in some sense.
    > >
    > > Of course. But that just trivializes the comment.
    > I took your reference to "political concerns" to be trivializing the
    > concerns,

    That was not the intention, though perhaps it sounded that way.... I take
    your concerns every bit as seriously as I do those of the Biblical Hebrew

    >If there were no stakes, we could change Unicode daily according to
    > the best current notion of technical excellence.

    'We' do in fact change Unicode (nearly) daily every time there is a
    revision. The question at hand is where to draw the line. Your position is
    crystal clear, and I am not questioning the reason why you make it, or the
    value in it. But

    > "Alienate major customers now, or alienate a relatively small customer

    the relatively small customer has every right to argue his/her case, and to
    hope for an implemention which will address his/her needs. The cost of
    kludges vs. corrections is not in the least analogous to your statement:
    both customers can--at least in theory--be satisfied, with some give on both

    If Unicode 'botched it up the first time' (not that I'm necessarily saying
    it did, but let's say so for the sake of argument), is it reasonable for the
    major customers to insist that the solution lies in botching it further?
    (and so on...)

    I agree that stability is sometimes preferable to (not necessarily better
    than) correctness. But a stable product which does not address the purpose
    for which it was created is definitely not preferable to one which is
    corrected to suit the purpose (the risks therein being acknowledged). Of
    course, one may object that the present implementation was not created for
    or to include BH in the first place, and that may be (I'm happy to be
    informed if that is so. But that isn't the impression the discussion thus
    far has made).

    (If not, then one must ask whether the present implementation can be
    reasonably extended (thus preserving the stability of the existing platform)
    or whether one must create a new, parallel implementation for the new
    purpose, [or some combination of the two] which is where most of the
    discussion seems centred.)


    This archive was generated by hypermail 2.1.5 : Fri Jun 27 2003 - 13:54:27 EDT