Re: String name and Character Name

From: Peter Kirk (peterkirk@qaya.org)
Date: Mon Apr 25 2005 - 16:04:00 CST

  • Next message: Curtis Clark: "Re: String name and Character Name"

    On 25/04/2005 20:13, Kenneth Whistler wrote:

    >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.
    >
    >

    Well, it seems that there is some uncertainty here in the standard. I
    rejected the statement that "all Unicode character names are adequate
    for their intended purpose", and in response Asmus wrote:

    > Not so fast here. The intended purpose of the character names is very
    > much at issue here, and it does not explicitly include the task of
    > supporting users in identifying characters.

    So what are you saying? That use of names in the UI is intended, but
    only implicitly? If so, and since there are a few character names are
    not adequate for use in the UI, it is untrue that "all Unicode character
    names are adequate for their intended purpose". Or are you saying that
    use of names in the UI is not intended, but nevertheless has happened?
    In that case, surely there is a need to make this clear in the text of
    the standard, to at least discourage software implementers from using
    the names in unintended ways. But it just doesn't work to sit on the
    fence, to refuse to say whether this usage is intended or not intended.

    Anyway, the statement "some aliases may be useful alternate choices for
    indicating characters in user interfaces" logically implies that there
    is some first choice other than aliases, and in the context this first
    choice must be the Unicode character name. Anyone reading this passage
    would take it as implying that "Unicode character names may be useful
    for indicating characters in user interfaces". So do you mean this, or
    don't you? Or is it a matter on which the UTC is split?

    >>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.
    >
    >
    >
    Well, if this is not what Asmus meant, if in fact the UTC is quite happy
    that Unicode character names are used in UIs (although for some reason
    it prefers not to make this explicit), then I return to what I wrote
    nearly a week ago:

    >
    >> a non-existent problem... all Unicode character names are adequate
    >> for their intended purpose
    >>
    >
    > Totally untrue! Some of the errors are simply annoying, but others (if
    > displayed to users) cause users to choose the wrong character and so
    > lead to total confusion.

    >>>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.
    >
    >

    This seems to be the plain meaning of Asmus' words, except that perhaps
    I should have written "...any intended meaning". If Asmus was mistaken,
    then I accept your correction. But this brings us back to the original
    point, that Unicode character names are inappropriate for one of their
    intended purposes, because several of them do not convey the intended
    meaning.

    >...
    >
    >
    >
    >>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.
    >
    >
    >
    Well, it is an interesting philosophical problem of whether a misspelled
    word has any meaning. What if the word could be a misspelling of two or
    more different words? Does it mean some mixture of the meanings of the
    two words? And what about the word "ion" if I type it in error for
    either "in" or "on", as I sometimes do? Does it mean an electrically
    charged atom? Can a word have a meaning which was not intended by its
    author?

    >>>... 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.
    >
    >

    I agree that I have learned that this is the position of some members of
    some committees. But I have not learned that it is sensible.

    -- 
    Peter Kirk
    peter@qaya.org (personal)
    peterkirk@qaya.org (work)
    http://www.qaya.org/
    -- 
    No virus found in this outgoing message.
    Checked by AVG Anti-Virus.
    Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 21/04/2005
    


    This archive was generated by hypermail 2.1.5 : Mon Apr 25 2005 - 16:06:04 CST