From keld@dkuug.dk Thu Sep 5 21:15:22 1991 Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA10728; Thu, 5 Sep 91 21:15:22 +0200 Date: Thu, 5 Sep 91 21:15:22 +0200 From: Keld J|rn Simonsen Message-Id: <9109051915.AA10728@dkuug.dk> To: wg15rin@dkuug.dk Subject: Re: (wg15rin 133) Ballot resolution X-Charset: ASCII X-Char-Esc: 29 Some comments to Gregers ballot resolutions: > Chapter 2.2: > =========== > > Replace line 367 with: > "The character order, as defined for the LC_COLLATE category > in the current locale (see 2.5.2.2), defines the relative order > of all collating elements, such that each element occupies > a unique position in the order. In addition, one or more > collation weights may be assigned for each collating element; > these weights are used to determine the relative order or > strings in e.g. the sort utility." Does this mean that you cannot define a collating sequence, which is indeterministic? We had trouble in DS defining such an indeterministic collation order when we started out some three years ago. Some in the DS i18n group said that they wanted an indeterministic order. How will the standard ensure that the collating order is deterministic? Will there be an error code? > Chapter 2.4: > =========== > Replace the last sentence on lines 1303-1304 with: > "The default character shall be the number sign (#). > This declaration shall only be specified if the coded > character set does not contain the number sign character." One of the main issues in RIN is that we advocate coded character set independent specifications of locales and charmaps. It then seems inappropiate to speak about specific coded character set specifications. Most charmaps and locales will hopefully be specified for a lot of character sets in the same source. It seems overly restrictive to hace to two last lines here, and I suggest that they be removed. > Insert after the first sentemce on line 1606: > This declaration shall only be specified if the coded > character set does not contain the number sign character." Same comment as above. > 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 qangle brackets, shall exactly match a symbolic name angle > 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 cooresponding 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. I suggest that the last sentence (and shall be replaced... ) be removed. It is too implementation oriented. > 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. > 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? > Replace lines 2333-2334 in draft 11 with the following: > "The directives that can be specified in an operand > to the order_start keyword are based on the requirements > specified in several proposed standards and in customary > use. The following is a rephrase of rules defined for > "lexical ordering in English and French" by the Canadian > Standards Association (text is brackets is re-phrased): > 1. Once special characters ([punctuation]) have been removed > from original strings, the ordering is determinded by determined > scanning forward (left to right) [disregarding case and > diacriticals]. > 4. If there is still an ordering equivalence after rules 1 > through 3 have been applied, then only special characters > and the position they accupy in the string are considered to occupy > determine ordering. The string that has a special character > in the lowest position comes first. If two strings have a > special character in the same position, the character [with > the lowest collation value] comes first. In case of equality, > the other special characters are considered until there is a > difference or all special characters have been exhausted." > > Delete lines 2344-2364 (Draft 11 line numbers). > > Lines 2530-2531: > The currency_symbol does not appear in the LC_MONETARY > category definition in the POSIX locale because it is > not defined in the C Standard's {7} C locale. > The C Standard {7} limits the size of decimal points > and thousands delimiters to single-byte values. In > locales based on multi-byte coded character sets this > cannot be enforced, obviously; this standard does not > prohibit such characters but makes the behavior > unspecified. I do not think we should limit ourselves to what C has limited itself to. The C standard is under revision and faults can be corrected there. Please do not remove "currency_symbol" as this is very much needed for i18n purposes. I cannot see how i18n applications dealing with monetary amounts can be localized without having a currency_symbol specification. In Denmark we could not have applications using "DKK " all over the place, when "kr. " is the much more accepted notation for ordinary amounts. Keld