From keld@dkuug.dk Fri Dec 3 22:26:30 1993 Received: by dkuug.dk id AA27598 (5.65c8/IDA-1.4.4j for i18n); Fri, 3 Dec 1993 21:26:31 +0100 Message-Id: <199312032026.AA27598@dkuug.dk> From: keld@dkuug.dk (Keld J|rn Simonsen) Date: Fri, 3 Dec 1993 21:26:30 +0100 In-Reply-To: Glenn Adams "Re: (XoJIG 1256) Re: (XoJIG 1254) Re: Extended Characters proposal ex WG20" (Dec 3, 20:45) X-Charset: ASCII X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Glenn Adams Subject: Re: (XoJIG 1256) Re: (XoJIG 1254) Re: Extended Characters proposal ex WG20 Cc: XoJIG@xopen.co.uk, i18n@dkuug.dk Glenn Adams writes: > From: keld@dkuug.dk (Keld J|rn Simonsen) > Date: Fri, 3 Dec 1993 20:21:46 +0100 > > There is a general recommendation from SC22 plenary not to deal with > semantics of 10646 level 2 and 3. That was why it was restricted to level 1. > > Since when did the parsing of identifiers in programming languages require > the analysis of semantics? Did the SC22 plenary accept the recommendataions of > the SC22 Adhoc on 10646 in Copenhagen? If so, one of the recommendations was > to support all 10646 characters, including levels 2 & 3. SC22 plenary in Paris in September dealt with the character ad hoc resolutions from Copenhagen, and passed most of them. Including the one on recommending programming languages to allow full level 3 data in data processing. One of the few recommendations, that was changed considerably, was the long term considerations on the ability to handle sematics of level 2 and 3. The Copenhagen meeting decided to recommend this, but SC22 plenary changed this to not do a recommendation, saying this was immature, and asking for input from member bodies and working groups on the issue; as I perceive it to purposely putting a resolution of the issue way ahead in time. > To take the issue up one level, why would SC22 avoid dealing with the semantics > of levels 2 & 3? Don't the realize it is necessary to do so? It cannot be > avoided for too long. You know there is resistance to level 2 and 3. SC22 said that the compiler technology is not there yet to be able to handle it. As all the conveners of the SC22 WG's were present the statement should be fairly representative of all SC22 language work. You have to consider the ISO process, which is sloo....*. EG COBOL is now working on extended character set support for 8-bit and Japanese like character sets, the amendment is scheduled for 1997. 10646 support is not considered here. They cannot take up new things before 1997, and then a number of things are on their list. The WG20 paper was a compromise that got consensus in WG20, and there were a number of things that had to be fiddled to reach this consensus. I beleive it is a great leap forward, and we can always do an addition to the list of characters. Anyway it was said that this was a preliminary list, meaning that WG20 is welcoming comments (thru your national body - well, WG20 has an open email list which you can also use for discussion of this matter: i18n@dkuug.dk) Keld