>From: Gavin Nicol, INTERNET:gtn@ebt.com
>TO: Jonathan Rosenne, 100320,1303
>CC: html-wg, INTERNET:HTML-WG@W3.ORG
>DATE: 06/05/96 12:00
>RE: Re: Copy of: I18N of HTML - Hebrew
>Sender: gtn@ebt.com
>>The specification should be modified as follows:
>>
>>The complete Unicode/UCS-2 character set is supported.
>>
>>Formatting code characters may be represented by named character
>>entities.
>This is because the directionality codes are not *characters* in the
>true sense of the word, but rather codes used to switch functionality
>from one mode to another. As scuh, they deserve the role of markup.
>
>In the I18N draft group, we discussed whether they should be markup,
>or codes, and decided on markup, because they are not really
>characters.
The way I see it, either you implement Unicode or you don't. I don't think
you can pick and choose. This is what standards are all about - after a
thorough and lengthy discussions, a concensus has been reached, and now
we want to move on. I don't see why we should reopen this discussion.
Some people don't like the formatting codes, they do not agree with their
ideas of what a character should be. Others don't like the way diacritics
are handled. Others don't like the naming convention. But the standards
represent the agreement reached on these subjects.
In Unicode, the formatting codes are regular characters. Definitely they
do not switch modes. In ISO 6429 similar codes set modes, but in Unicode
it is different. The only thing these characters do is help the implicit
algorithm get it right.
>Then we discussed whether we should define them as shortrefs, but
>given the pitiful state of SGML support in most browsers, we adopted
>the markup route.
I don't see how i18n can be supported, not just bidi, unless the
browsers are fixed in this respect, so I think this reason is
not very strong. I mean, you would have to use named character entities
to represent characters which are not available in the transmission
character set, which does not have to be UCS-2.
Regards,
Jony Rosenne
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:31 EDT