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 political > > > 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 community. >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 now." 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 sides. 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.) K
