Re: String name and Character Name

From: Kenneth Whistler (kenw@sybase.com)
Date: Mon Apr 25 2005 - 13:13:48 CST

  • Next message: James Kass: "Re: String name and Character Name"

    Peter,

    > In this case this is the irrefutable evidence that TUS recommends use of
    > Unicode character names in user interfaces,

    It does not recommend use of Unicode character names in user
    interfaces. Nor does it *dis*-recommend them.

    Section 16.1 of TUS, which is an *explanation* of the character
    names list -- not a distillation of normative decisions taken
    by the UTC to be read like the Unicode Code of Laws -- implicitly recognizes
    that some implementers will use (and have used) Unicode character
    names in user interfaces. It points out that aliases exist,
    and that "some aliases may be useful alternate choices for
    indicating characters in user interfaces." That seems like an
    eminently sensible piece of advice to me.

    > despite Asmus' statement
    > that an official decision had been made that are not suitable for this
    > purpose.

    That is *your* interpretation of what Asmus said. It is not
    *my* interpretation of what Asmus said. Nor does it accord
    with the facts. The UTC has *not* made any official decision
    to this effect.

    > > TUS says "unique and stable", TUS does not say "meaningless". ...
    >
    >
    > Indeed. But Asmus' point was that their purpose has been "deliberately
    > *reduced* to providing an unique and immutable identifier", which would
    > seem to rule out any use of them as having any meaning.

    Nonsense.

    Asmus' point is that the standardization committees do not
    intend to deep end in some foolish attempt to create an
    Encyclopedia of *Correct* Character Names. That is an impossible
    task for which there can never be completion or consensus, in
    many cases. (As amply demonstrated by more than a decade of
    arguing about character names on this list.) The committees
    do a reasonable job of attempting to create *appropriate* names
    for every character added to the standard, and go through
    cycles of revew and ballotting, during which many comments
    regarding names result in changes and fixes -- both for
    obvious typos and for more subjective preferences regarding
    one way or another to approach the name of a particular
    character. *Anyone* can get involved at that point and influence
    what may result eventually in a standardized character name for
    the UCS.

    But once publication happens, the door is closed on further
    fixes, whether based on subjective preferences, obvious errors
    (like KANNADA LETTER FA), or even typos. Those are the rules --
    they have been clear for years now.

    The committees recognize that the primary function of Unicode
    character names is to serve as a unique and immutable identifier.
    That constrains their choice and restricts their ability to
    be changes (or fixed). That does not, however, render them
    meaningless, nor does it strip them of other potential functions.
     
    > And of course
    > identifiers including words like BRAKCET are meaningless.

    That is of course *not* the case. "BRAKCET" is a typo for
    "BRACKET", and is perfectly meaningful.

    > > ... Of course,
    > > the names are intended to be meaningful, but -- as we have learned in
    > > this
    > > thread -- stability is considered more important than correcting the odd
    > > error in a name. ...
    >
    >
    > You and Asmus have asserted this, but I have not learned it.

    I would put it more that you have simply chosen to reject it.

    It is *manifestly* the case that stability of names is considered
    more important than correcting the odd error in a name -- by
    the members of the relevant committees. There not only is
    consensus on that point -- there is near unanimity, and has been
    for years.

    *You* may not consider it more important, but that doesn't
    change the way things are.

    --Ken



    This archive was generated by hypermail 2.1.5 : Mon Apr 25 2005 - 13:14:40 CST