W3C home > Mailing lists > Public > www-international@w3.org > October to December 1996

Re: Clarification of discussion

From: Martin J Duerst <mduerst@ifi.unizh.ch>
Date: Thu, 24 Oct 1996 22:47:17 +0100 (MET)
To: avine@dakota-76.Eng.Sun.COM (Andrea Vine [CONTRACTOR])
Cc: www-international@w3.org, avine@dakota-76.Eng.Sun.COM
Message-ID: <"josef.ifi..658:"@ifi.unizh.ch>
Andrea Vine wrote:

>I am trying to follow this discussion as it pertains to the original
>question (which I've long since deleted, due to space considerations).

Thanks for bringing us back.

>Am I to understand that from what Keld, Martin, and Jonathan are saying,
>you cannot "have your universal CLASS and name it too?"  (This is a play
>on an English expression, sorry for those not familiar.)  What I mean is,
>it sounds to me that in order to have a universal CLASS name/definition/
>type/whatever the original question was, it would have to be constrained
>to Latin-1 characters with no inscripts, subscripts, or superscripts,
>glyphically speaking.  The characters must have unambiguous Unicode/10646
>If the CLASS name/definition/type/thing is named using anything other
>than these characters, then the implementation would be locale and
>language specific.

It's a little bit different. What we are arguing about currently is
whether ISO 10646 is prefering some encoding over another, or prohibiting
one of them. We agree that it does not say that some encodings are
equivalent to others. On the other hand, we agree that there are
cases where, if there are different encodings, they would not
be distinguished, or should not be distinguishable, to the user.

For a concrete case, take the letter A with a grave accent above it.
There are some systems that may encode it with a single codepoint,
whereas others will combine it from A and combining grave.
This could be extremely confusing to the user. There are three
possibilities to deal with this (on which, I guess, we all agree):

(1) Put the burden on the user.
(2) Put the burden on the rendering engine (which has to treat as
	equivalent those two (in some cases even more) representations).
(3) Define some kind of preferred encoding, and require that all CLASS
	names use it, so that comparison is simple.

You added to this:
(4) Use only characters where there is no such problem.

Solution (1) or (4) is not really what the user wants. Solution
(2) is probably what we are heading for, although it also has
some disadvantages. Solution (3) has the problem that we need
to specify more, in an area where it is very difficult to find

Regards,	Martin.
Received on Thursday, 24 October 1996 16:47:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:16 UTC