Two different sets of experiences about non-English identifiers (fwd)

---------- Forwarded message ----------
Date: Mon, 16 Jul 2001 15:39:27 +0900
From: Joel Rees <rees@server.mediafusion.co.jp>
Reply-To: Joel Rees <rees@mediafusion.co.jp>
To: Don Park <donpark@docuverse.com>
Cc: xml-dev@lists.xml.org
Subject: Two different sets of experiences about non-English identifiers

Don Park expounded:

> HUMAN FACTOR:
>
> We engineers often forget that, while technical aspect of translating
native
> tag names to another language might be trivial, human factors are not.
For
> example, people using the target tag names will not be able to communicate
> well with the original group nor groups using different target tag names.
> This problem can be minimized by using phonetic translation (i.e. Gaijin),
> but the problem does not go away.

My experience is that using the romaji here in Japan generally tends to
compound problems. For single vocabulary words (gaijin, romaji, kimono)
dragged out of context, they can be useful. For Japanese language textbooks
for beginners, they can be absolutely required. For me, taking down notes
during meetings, romanizing is often convenient. But I would not want to use
a romanized DTD. Too many chances for confusion on the homonyms, and
confusion on the meanings of foreign terms is a serious enough problem as it
is.

To be looking at phonetic transliteration is looking in the wrong direction,
anyway.

> CODE FACTOR:
>
> XML applications recognize tags by tag names.  Unless XML applications are
> designed to support multiple native tag names, code must be modified for
> each target language and repeat for each update.  Translating code is
harder
> than translating data.

I don't think much code needs to translated at all.

Imposing a whole new set of operating software (and the operating procedures
that go with it) on the new partner/subsidiary will be extremely expensive,
regardless of the language the tags are written in. Better to set up an
interface, and transform the data shared as it crosses the interface. Tag
names also can (and probably ought to) be transliterated at the interface.

> BUSINESS FACTOR:
>
> Today's globalization trend makes it less likely for a business to stay
> within its national border during its lifetime.  Unless native tag names
is
> being used as a form of anti-takeover mechanism, I donot see a compelling
> and tangeble reasons not to prepare for likely future.

<teasing>IMPERIALIST PIG!</teasing>

On a serious note, however, globalization is a fad. A fad useful to various
proselytizing communities, but a fad nonetheless. Like all fashion, it is
based on an illusion. Very few businesses can afford the cost of becoming
suddenly international.

Admittedly, if this present civilization survives very long, many businesses
will increase their participation in international commerce. But if I look
at the advantages of imposing some (necessarily foreign) set of DTDs written
in some internationally accepted language, as opposed to letting businesses
define their own data structures in their own language and then define
transforms to interface their systems to the larger context, I see nothing.
No advantages whatsoever.

In fact, the imposition from the outside simply will not work, unless a
company already has a very clear definition of their data structures to
start with. You may perceive the foreign language tags as an avoidable cost,
but I perceive them as an enabler, as one (possible) useful product of a
very necessary step.

> There are probably other factors involved, but these are some I can think
of
> at this time.  Comments?
>
> Best,
>
> Don Park

Don,

You talk about the human factors. It seems to me that you are suggesting
that the solution is to proselytize American standards all over the world.

I am an American. I look around me at (for example) the Japanese trying to
run a stable government under a rough transliteration of a mid-twentieth
century idealistic interpretation of the US constitution and I am amazed at
their resourcefulness. There is a lot of stuff in that constitution that
simply works backwards, due to things we quite casually blanket over with
the short phrase "cultural issues", wave our hands at, and try to forget. It
was probably the best that could have been done, but it still creates
problems.

Locality of control is a very important principle in engineering. (Lengthen
the control lines, and you introduce both noise and spurious function. Both
increase proportional to the length of the control lines.) To my way of
thinking, requiring XML authors to use tag names borrowed from a foreign
language flies directly in the face of the principle of locality of control.

My comments.

Joel Rees
programmer -- rees@mediafusion.co.jp
----------------------------------------------------
To be a tree supporting all information,
  giving root to the chaos
    and branches to the trivia,
      information breathing anew --
        This is the aim of Yggdrasill.
============================XML as Best Solution===
Media Fusion Co. ,Ltd.  株式会社メディアフュージョン
Amagasaki  TEL 81-6-6415-2560    FAX 81-6-6415-2556
    Tokyo　TEL 81-3-3516-2566  　FAX 81-3-3516-2567
                       http://www.mediafusion.co.jp
===================================================



------------------------------------------------------------------
The xml-dev list is sponsored by XML.org, an initiative of OASIS
<http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: xml-dev-request@lists.xml.org

Received on Monday, 16 July 2001 07:31:49 UTC