[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Two different sets of experiences about non-English identifie rs

  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • To: xml-dev@l...
  • Date: Fri, 13 Jul 2001 16:27:14 -0500

two different business
On my mantle is a Buddhist holy name given me 
by my Korean master, Kyung Bo Seo.  He sensibly wrote the name 
in both his native script and in transliterated 
English.  As a result, today, I can still remember 
my Sangha name (I can't read the script) and have a work on my mantle that
is 
both beautiful, evocative and valuable (he 
is a world recognized master in the artform).

It isn't that hard and the cost is nothing 
compared to the benefit.  All things are 
not strictly business decisions.  Some are 
matters of human values.  If we believe XML 
is not to be subject to such values, that it 
is instead, strictly a tool of business, then 
XML should and must always be subordinate to 
SGML, a better design created by smarter 
people for a customer that understood completely 
the phrase "Good fences make good neighbors."

A choice is provided.  Choose according to 
your values.  Do not let others choose for you 
unless the options are of equal value and neither 
has a significant discriminator.

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Don Park [mailto:donpark@d...]
Sent: Friday, July 13, 2001 4:09 PM
To: xml-dev@l...
Subject: RE: Two different sets of experiences about non-English
identifiers


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.

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.

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.

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

Best,

Don Park


------------------------------------------------------------------
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@l...

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.