From keld@dkuug.dk Thu Sep 19 20:04:30 1991 Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA01982; Thu, 19 Sep 91 20:04:30 +0200 Date: Thu, 19 Sep 91 20:04:30 +0200 From: Keld J|rn Simonsen Message-Id: <9109191804.AA01982@dkuug.dk> To: greger@ism.isc.com Subject: Re: (wg15rin 142) Re: Ballot resolution Cc: wg15rin@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 Greger wrote: > In reply to your message of Thu Sep 5 22:00:32 1991 > ------- > >Some comments to Gregers ballot resolutions: > > >> Change line 1622-1625 to: > >> "(1) A character can be represented via a symbolic name, enclosed > >> within angle brackets (< and >). The symbolic name, including > >> the angle brackets, shall exactly match a symbolic name > >> defined in the charmap file specified via the localedef -f > >> option, and shall be replaced by the corresponding value > >> from the charmap file." > >> > > >I am not sure this is the only - nor best - way to do it - replacing > >the symbolic name with the corresponding value from the charmap. > >I have ideas on having all of the charmaps translate into some kind > >of widechar value (with widechar maybe defined by the locale appearance). > >This may define some tables which are a lot smaller than prescribed > >by the above specifications. > > However, I suggest (Hal!!!!!) the following text instead: > > "...option; and shall be replaced by a character value > determined from the value associated with the symbolic > name in the charmap file." That would be OK. > >> Add after line 1662: > >> "If a charmap file is present, only characters defined > >> in the charmap shall be specified." > > >I do not have the draft present, but does that eliminate the possibility > >of defining charset independendent locales. That would indeed > >be a pity. > > You are right, and that was not intended. What the balloteer wanted to > stop was the ability to define characters not existing in the character > set. A better text would be (Hal, note!!!!!!) > > "If a charmap file is present, only characters defined in > the charmap shall be specified using octal, decimal, or > hexadecimal constants. Symbolic names not present in the > charmap file may be specified and shall be ignored, as > specified under (1) above." That is indeed a better wording. Anyway I have ideas that characters could be specified in the locale with numbers, which were outside the charmap values, like a unicode/10646 locale being used with some ibm pc codepage, and the unicode/10646 locale having numbers for some of the characters. These values should be ignored, like the non-present symbolics. Another thought: can you really allow such values to be invalid? If I would want a sequence of characters to mean something special, should I be precluded from specifying such an object in the locale? Like say having ")>" always meaning right-curly-bracket ? Or having "aa" meaning a-with-ring ? > >> Delete lines 1958-1959. (substitute) > >> > >> Delete lines 2137-2157. (substitute) > >> > >> Delete lines 2180-2183. (substitute) > > >Does that mean that the substitute command is eliminated? > >Is that OK with the japanese? > > It seems so... or I will get other ballots! DS will not make ballot comments on this at this moment. We have been advocating not to use substitute for a long time. On the other hand, substitute seems adequate for sorting on a higher abstraction level, like dictionary level, and although this is not what RIN plans to produce for national locales, applications (and this is what POSIX is all about!) may need such facilities. Also WG20, in doing collation sequence specifications for applications, will need something like substitute. If we want WG20 to take over our specifications, it might be wise to cater for such needs. > We are not eliminating currency_symbol; we are saying that the C > locale doesn't have any value there (see ANSI C standard). OK. Keld