Re: Two different sets of experiences about non-English identifiers

[Joel Rees <rees@server.mediafusion.co.jp>]

Don Park <donpark@docuverse.com> considered:

> Were your co-workers schema designers, programmers, systems integrators or
> end users?  If some of each, were there any differences in how much
> differences native language tag names made?

Yes. Everyone here does a little of everything. But any way you look at it,
Japanese markup is easier.

> What we need is better understanding of issues surrounding non-ASCII tag
> names and better tools.

Agreed.

> It is my opinion that XML WG tried to solve too
> many problems through XML features when tools and education could have
> provided better if not more natural solutions.
>
> When I mentioned English in my previous messages, I really meant to say
> ASCII.  I cannot ignore the fact that ASCII is uniquely available on all
> computers with text input and output.  All computers know how to display
> ASCII and all keyboards support ASCII input and most even have printed
> labels for ASCII.  I am not aware of any other language that offers
similar
> universal availability.

How much of the history do you want here? There are computers in use that do
not deal with ASCII. For instance, some systems in Japan use the older JIS
encoding (as opposed to shift-JIS or JIS-euc), and that has Latin
characters, but the organization is not algorithmically related to ASCII,
and the translation to/from ASCII is not one-to-one. I seem to have the
impression that there are some systems in some countries that don't do ASCII
at all.

> Immediate advantages of native tag names cannot be denied, but at what
cost?
> Yes, little XSLT or Perl can translate, but cost of realizing 'can' is not
> zero.  A Korean bank, which decided two years ago to use native tag names
> companywide, now has to merge with an American bank, some heads will roll
> when the CEO is faced with the bill.  My point is that we donot
understands
> the issues fully, and we need to find out before such practice becomes
> unreversably common.

"If we'd only known!" is a phrase that will be repeated as long as humans
are mortal. Not every bank will merge with a foreign bank. Those that do had
better include document conversions in their new operations plans and the
cost analyses.

One of the famous soap companies here reportedly does all their internal
operations in English. This company puts a lot of money into making it work
(mandatory English lessons with foreign teachers who are also on the
payroll, as an example). I talked to a guy that used to work for them, and
he says that for all that they spend, it doesn't really happen.

The only organization in such a merger that makes sense to me is to define
an organizational interface, and convert at the interface. Lists of
translations of terminology must be available for the humans. Markup
translation lists can be generated from those, and the filters installed in
the pipes at the interfaces. (For large companies, I'd suggest such an
approach even if language were not a problem. It's a principle called
locality.)

No, the filters don't cost that much to build, and once they are in place,
they hardly cost anything to run.

Cheers,

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
===================================================