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: Tue, 29 Oct 1996 13:28:42 +0100 (MET)
To: masinter@parc.xerox.com (Larry Masinter)
Cc: Chris.Lilley@sophia.inria.fr, avine@dakota-76.eng.sun.com, www-international@w3.org
Message-ID: <"josef.ifi..886:"@ifi.unizh.ch>
Larry Masinter wrote:

>> b) To turn case (3) into case four, some concious effort is needed.
>>	Otherwise, neither French nor German nor Spanish will ever
>>	make it into classnames, whereas Russian, Hindi, or Japanese
>>	won't have any problems.
>Yes, but we need not wait until this effort has happened to
>proceed, and it will make it clear what the nature of the difficulty

I generally like flexible approaches, and in this light, your
idea has a lot of appeal. I could certainly approve for cases
such as Arabic, where ligatures and stuff are defined in the
compatibility zone, and I would expect most systems to only
use the base letters in URLs.

However, we already know a lot of the nature of the difficulties.
We definitely know that it doesn't make sense to treat A-Grave
and A followed by combining-grave as two different things.
We know that this might cause heavy difficulties and unexpected
results for the users. We also know that it's a different thing
of whether equivalence will be used at the resolver, or normalization
at the client. In addition, we know that there are vastly differing
ideas as to what is the most natural thing to do in such a case.
Some people in the business claim that decomposition is very
straightforward and should always be used, others claim that
precomposed characters should be used because the standards
specify it this way (or that's what they think they do), and
if any combination is found missing, it should be added.

Giving the above knowledge, I guess some action rather soon
on this issue might be preferable to just a "wait and see"

Regards,	Martin.
Received on Tuesday, 29 October 1996 07:29:51 UTC

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