From alb@riq.qc.ca  Sun May 11 00:07:08 1997
Received: from socrate.riq.qc.ca (socrate.riq.qc.ca [199.84.128.1]) by dkuug.dk (8.6.12/8.6.12) with SMTP id AAA01065; Sun, 11 May 1997 00:07:05 +0200
Received: from 571 (riq-44-132.riq.qc.ca) by socrate.riq.qc.ca (5.x/SMI-SVR4)
	id AA21831; Sat, 10 May 1997 18:12:52 -0400
Message-Id: <3.0.1.32.19970420190550.006e8af0@mail.riq.qc.ca>
X-Sender: alb@mail.riq.qc.ca
X-Mailer: Windows Eudora Pro Version 3.0.1 beta 14 (32) [F]
Date: Sun, 20 Apr 1997 19:05:50 -0300
To: Misha Wolf <misha.wolf@reuters.com>,
        Multiple Recipients of <unicode@Unicode.ORG>
From: "Alain LaBont/e'/" <alb@riq.qc.ca>
Subject: Re: &xnnnn;
In-Reply-To: <9705101652.AA17662@Unicode.ORG>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

A 09:52 10/05/97 -0700, Unicode Discussion a écrit :
>At the HTML WG meeting, I hope to help sort out the various i18n-related 
>errors in Cougar.  This mail deals with one point which is a proposal rather 
>than a bug report.
>
>As:
>
>1.  the Cougar document character set is ISO 10646/Unicode, and
>
>2.  that standard uses a hexadecimal character numbering scheme, and
>
>3.  not many people are good at doing hexadecimal-to-decimal conversion in 
>    their heads,

[Alain] :
Just because of this, the ISO/IEC 14755 (Input methods to enter UCS
characters) uses the notion of "catalog number" for characters. End users
all are familiar with the notion of catalog number. In ISO/IEC 14755 this
notion is now standardized in thinking about end users and the fact that
UCS/UNICODE ids are in hexadecimal only (these are the character catalog
numbers). Hence in using such a catalog number end users don't need to be
aware about hex to decimal conversion or to binary...

[Misha] :
>it would be helpful to allow hex NCRs.  It would be best to follow the XML 
>syntax for this and follow the "&" with an "x".  All of these represent the 
>same character:
>
>   A
>
>   &65;
>
>   &x41;  
>
>Note: ISO 10646/Unicode allows more than four hex digits and so
implementations 
>should be built to cope with NCRs such as "&xnnnnn;".  [...]

I agree with this.

Alain LaBonté
Québec