[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML Blueberry (non-ASCII name characters in Japan)
- From: Murata Makoto <firstname.lastname@example.org>
- To: email@example.com
- Date: Sun, 08 Jul 2001 01:40:19 +0900
> > So I think it would be appropriate, in this discussion,
> > to have some people in the mainframe trenches give us
> > a briefing on the scale and the difficulty of the problems
> > they face, and for some of our i18n gurus to highlight
> > the problems faced by an XML language designer who wants
> > to use one of the newly-added languages.
> I second this.
Summary: Japanese characters have been heavily used for tag names
and they have been very useful. Addition of more characters
(CJK ideographics introduced in Unicode 3.1, etc.) is intensely
1. Current Status
XML 1.0 provides name characters for the Japanese language. Since the
inception of XML 1.0, people have used Japanese name characters
for XML. I believe that such use is very common.
Some people use Japanese name characters wherever possible. Reasons: (1)
the Japanese language is natural for Japanese, (2) translation to English
is sometimes impossible because of cultural differences , and (3) some topics
(e.g., Buddhism research) are specfic to Japan or Asia.
For example, an XML-based language for medical information uses
Japanese name characters. This language has been designed by doctors
who read and write English well. Nevertheless, they have chosen Japanese
names because some terms simply cannot be translated to English.
Buddhism researchers have created a few DTDs which heavily use non-ASCII
name characters. Such names are very difficult to translate to English.
Even when such translation is possible, these researchers want to use
non-ASCII names very much.
One of my DTDs is used for data interchange between two companies. This
application is not experimenal but already plays a very important role in
their main business. All tag names in this DTD use Japanese characters.
As far as I know, they have not cause any problems. To the contrary,
they are helpful in debugging, etc.
Others discourage use of Japanese name characters. The reason is that
some XML tools (e.g., CSS of Microsoft IE5.5) fail to support non-ASCII
markup characters. I think that such XML tools are broken and we should
try to change this situation.
2. Useful Additions.
To my regret, KATAKANA MIDDLE DOT (which is used to connect two
names) is missing in the list of name characters of Unicode 2.0 and
thus it is also missing in XML 1.0. As a result, quite a few Japanese
users have complained about this omission. Addition of this character
will make a lot of Japanese users happier. To me, this is already
a good enough reason to create XML 1.1.
Unicode 3.1 allows so many CJK ideographics. Quite a few people expect
that these characters will also be allowed as name characters.
Unlike Rick Jelliffe, I don't agree that newly introduced CJK ideographics
are archaic. First, national standards (e.g., JIS and CNS) have revisited
unification: what was unified as a single character has occasionally become
two characters. One of the two characters has become a non-BMP
character. Second, quite a few Chenam characters are non-BMP characters.
Some of the compatibility ideographics, namely U+FA0E, U+FA0F, U+FA11,
U+FA13, U+FAF14, U+FA1F, U+FA21, U+FA23, U+FA24, U+FA27, U+FA28, FA29,
has become normal ideographics AFTER XML 1.0 was created. Addition of
these characters is very useful.