[SML] Preliminary EBNF for SML

Rick Jelliffe ricko at allette.com.au
Sat Nov 27 06:05:53 GMT 1999


 
From: Don Park <donpark at docuverse.com> 

 >The reverse is not true.  I dare say that every engineer
>in the world knows enough English to understand English
>tag names and attributes names with the aid of readily
>available dictionary.  Ask any foreign engineers if they
>use names in English or their own language when they name
>C or C++ identifiers.  Ask any foreign engineers if they
>did not have some English training even before College.

You would be entirely mistaken in this.  Engineers in Africa 
may have  French as their second language; engineers from 
ex-Eastern Bloc countries will have Russian as their second language.
Engineers in China will have Mandarin as their second 
language.  And the skills of reading and writing are different:
many people can recognise English words in context but 
cannot recall them.  Asking professional people in America 
if they  speak English hardly proves anything.

And are you saying that SML is a language that only 
engineers should read and write?

>Internationalization is also less of a problem than you
>think. 

This is utterly bogus.  Every different language and domain
area has different problems.   

> Translating English name to foreign words usually
>results in a weird words.  Just ask any foreigner with
>foreign version of Windows if the menu commands made good
>sense to them when they first started using it.  The fact
>is that when a person learns how to use computers in non-
>English speaking countries, they have to learn a whole new
>set of words consisting of old or uncommon words overloaded
>with new meanings.

So we should perpetuate this and make it worse?  And it is not
correct to suggest that a foreign version of Windows has menu
items that are simply the English words transliterated or directly
translated. Of course there is a set of meanings of words to learn;
but why should their be a foreign vocabulary as well? 

>Also, we are going to have a big problem with schema
>differences in the future and I would rather not have
>foreign language variations of common tags like <name> and
><address> in the pot as well.

Is this any difference from saying "I don't care how difficult it
is for losers who find English difficult, as long as it is convenient 
for me?" 

Furthermore, there are many terms that do not have exact
translations.  What is the English equivalent for the Japanese
address unit "cho"?   I helped an accountant at my work
try to develop standard English translations for payroll
deduction terms here in Taiwan, and there are many which
simply are not found in English: without a really complicated
explaination with multiple English words there is no way
to give the same markup: looking up words in a dictionary
is not a productive use of time.  Such systems would require
an extra layer of software to provide UI help, in which case
the advantage of "simplicity" is lost.

I agree that it is good to have standard
terms for common things, and that English is the best choice
at the moment, but unfortunately not every word exists in 
English and most people in the world do not speak it or read
it.

Why reduce markup to mere nmemonics rather than be able
to use names?   

One reason for allowing native language markup is that it
can enfrachanchise the great proportion of the world who
are literate but not in English.  The goal of markup 
systems should not be to make life easier for programmers,
but to reduce the requirement for extraneous-to-the-task skills 
as markup is used instead. These extraneous skills should include
both programming and English-knowledge.

Rick Jelliffe
Taipei, Taiwan


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)





More information about the Xml-dev mailing list