From: Karljürgen Feuerherm (firstname.lastname@example.org)
Date: Fri Jun 27 2003 - 13:22:42 EDT
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
> > > > 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
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