[
Lists Home |
Date Index |
Thread Index
]
- From: Rick JELLIFFE <ricko@geotempo.com>
- Date: Sun, 16 Apr 2000 20:39:56 +0800
Don Park wrote:
> My understanding is that most software engineers, no matter where they
> are, can read English well enough to distinguish and infer enough
> meaning from English element types to use them. In Korea, for example,
> English is everywhere and most Koreans can recognize the words even if
> they can't pronounce them.
But that is begging the question. The more technology is difficult
for non-English users to use, the fewer non-English users there will be.
In any case, it is not true. Here is Taiwan, almost all Microsoft
applications
are localized and no-one uses anything else. For databases, people will
use
Chinese names where possible.
As for ASCII characters being available on a keyboard, there is the fair
question of "what about transliterating the local language into the
latin
alphabet?", but that has problems for tonal languages, or languages
where
there are many homophones. And many people don't know the standard
orthography anyway: here in Taiwan my local street is spelled 3
different
ways and there are 3 different pronunciations anyway depending on the
language used.
In any case, XML data is often sourced from databases, and there are
databases
with native-language fieldnames.
And there is another big issue in approach too, which goes to the heart
of
what is "interoperability": should it be easier to send data to
someone on the other side of the world than to someone at the next desk?
I think standards which make local transport more difficult offer a
bogus kind of interoperability: data transfer is more often local than
to far away. (Which is why a UTF-8/UTF-16-as-the-only-encodings-allowed
approach seems to have failed when it has been tried. Look at WAP:
they are developing it in their local encodings and figuring out
how it fits together afterwards: it is pragmatic to support that
approach, though it is slack.) English-only fits into that kind
of bogus interoperability, unless we are creating a world of only
Big Schemas.
I would hope that the advent of namespaces can allow more extending
of schemas, even though the base schema may well be in English
acronyms. (B.t.w., I think XML Schemas does provide support for
multilingual architectures--these are not marked up explicitly
but derived during document traversal: I think an XML Schema
with abstract elements is nothing more than a base architecture.
In practise, you define your Schema in the canonical language,
then derive [by reproduction, on draft said] various concrete
DTDs using native-language tagnames. Your abstract schema
says "potato" and my concrete schema says "potato".)
> Of course, we are talking about simple or
> well-known words like office, automation, web, starcraft, order, name;
> not words like pedantic.
I think any schema rapidly becomes technical. I think Don would be
particularly interested that words like "pedantic" are rarely
used for element names: adjectives tend to be given by attributes.
It is interesting to speculate that someone from a language which
had little distinction between adjectives and nouns might find it
unnatural to have elements and attributes, while someone
whose mind was formed learning a language with a sharp distinction
may find the element/attribute distiction completely natural.
But instead, I wonder if a case could be made that, for languages
which have no lexical difference between words used adjectivally and
words used as nouns, the provision in XML of elements and attributes
may provide a needed grammatical indication of which role the
word should serve?
If this seems a pretty thin speculation, I hope it is not pedantic or
rude of me to think that "most software engineers...can read English"
is too?
Rick Jelliffe
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|