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

[XML Everywhere <host@xmleverywhere.com>]

English is the lingua franca for business, ergo XML
tags should only contain ASCII.  That's a good
guideline if you're writing a  DTD for commerce.
But other applications need not heed this advice.

I do not completely understand Unicode or character
encodings in general.  Few people do and fewer
tools support them.  Operating systems don't
handle non-ASCII code pages very well.

Those are good reasons to be cautious.
But character encoding issues
apply equally well to the whole
document, not just to names.

As of yet, nobody has made a good argument
as to why XML names are so restrictive.

Who hasn't been surprised and a
little miffed that values for "ID" attributes
can't start with a number?

It's fine to reserve some characters
for future use (such as punctuation),
but an element name is not
like a C++ variable name.  At
least there is no good reason why
they should be restricted as such.  It's
just what the gods decided at the
time, probably because they are, of course,
programmers.

So gods, explain yourselves.  Or,
being gods, you have the luxury
of not having to answer to anyone.

----- Original Message -----
From: "Don Park" <donpark@docuverse.com>
To: <xml-dev@lists.xml.org>
Sent: Thursday, July 12, 2001 10:29 PM
Subject: RE: Two different sets of experiences about non-English identifiers

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.