From erik@sran8.sra.co.jp Thu Dec 13 14:17:24 1990
Received: from mcsun.EU.net by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8)
	id AA01493; Thu, 13 Dec 90 14:17:24 +0100
Received: by mcsun.EU.net with SMTP; Thu, 13 Dec 90 14:16:28 +0100
Received: from srava.sra.co.jp by srawgw.sra.co.jp (5.64WH/1.4)
	id AA22795; Thu, 13 Dec 90 22:15:26 +0900
Received: from sran8.sra.co.jp by srava.sra.co.jp (5.64b/6.4J.6-BJW)
	id AA00668; Thu, 13 Dec 90 21:43:18 +0900
Received: from localhost by sran8.sra.co.jp (4.0/6.4J.6-SJ)
	id AA23964; Thu, 13 Dec 90 21:38:52 JST
Return-Path: <erik@sran8.sra.co.jp>
Message-Id: <9012131239.AA23964@sran8.sra.co.jp>
Reply-To: erik@sra.co.jp
From: Erik M. van der Poel <erik@sra.co.jp>
To: i18n@dkuug.dk
Cc: XoTGinter@xopen.co.uk
Subject: Re: (i18n 46) Re: Japanese Profile
Date: Thu, 13 Dec 90 21:38:50 +0900
Sender: erik@sran8.sra.co.jp
X-Charset: ASCII
X-Char-Esc: 29

> > The interpretation of ellipsis (...) depends on underlying encoding.
> > For example my definition will work for encoding so-called 7-bit-
> > JIS (which are used in JUNET) as well as UJIS, but will not on
> > Shift-JIS nor Kanji codes which are not based on JIS X0208.
> > 
> > Sekiguchi
> 
> I don't think it is a question of whether or not it will "work". If
> the system is implemented properly, it should collate even Shift-JIS
> exactly as you specify in your ellipsis definitions. Of course, it
> cannot be as efficient as JIS, since there is no one-to-one
> relationship between the collation definition and the Shift-JIS code.
> 
> Erik

Oops, I just realized that I made a mistake. The character ranges in
LC_COLLATE are *not* based on the symbolic names in the ranges, they
are based on the encodings of the characters.

I was thinking of the *charmap* proposal, where the ranges *are* based
on the names, e.g.:

	<j1601>...<j1694>


Now I'm beginning to wonder about the LC_COLLATE specs. The charmap
concept was introduced in order to be able to free the locale
definitions of any encoding dependencies. Yet, the LC_COLLATE ellipsis
specs are explicitly encoding dependent. Isn't this rather
inconsistent?


Erik

