In message <[EMAIL PROTECTED]>, gra
[EMAIL PROTECTED] typed:
>>Let's consider a few basic principles.
ok - lots of good points below - a few responses...
>>1. Neither ASCII nor XML are ever displayed. They are CODES for
>>representing characters in a computer. It is the CHARACTERS ( glyphs ) that
>>are displayed ( presented / rendered ). There is a mapping between the codes
>>and the glyphs.
but the glyphs are in HARDWARE in many devices(e.g. printed on
keycaps, in printer wheels, in crt display chips etc)...
>>2. ASCII has a strictly limited set of characters and glyphs ( even the
>>"international" version ), which can not represent many languages in the
>>world, and does a poor job of rendering diagrams, pictures, etc.
yes, this point has been made a lot - however, the discipline of
getting a diagram into ascii art has OFTEN caused people in the ietf
to udnerstand the problem better (e.g. by choosing the most
parsimonious topology to explain a partiocular routing problem)
>>3. As some people have emphasised, the importance of ASCII lies in the (
>>American Standard Code for Information ) INTERCHANGE. Interchange implies
>>the ability to transfer in a manner which can be understood by both parties
>>to the transfer. The MOST COMMON global method of transferring will be the
>>most effective.
yes, yes, and yes......but also, collating, indexing, and searching -
manmy of the search engines are optimised to the roman alhpabet, the
english dictionary, and the english freqeuncy distribution of
words....
>>4. Interchange does not guarantee understanding - either of presentation
>>format or content. I wouldn't like to have to deal with Einstein's Theory
>>of Relativity ( content ), especially in Chinese ( format ). ASCII does not
>>interchange Chinese characters, so it's presentation format is NOT readily
>>understandable by "most people".
>>
>>5. A more comprehensive coding scheme, such as the Universal Character Set
>>( ISO 10646 ) would allow many more characters and glyphs to be used.
>>
>>6. The key to usage of encoding schemes is how widely they can be
>>interpreted by character presentation ( or rendering ) applications ( word
>>processors, etc. ), in mapping the internal codes to the glyphs rendered on
>>the screen or on paper. Applications which can render more characters would
>>allow the use of larger code ranges and more characters.
>>
>>Until something replaces ASCII as the most commonly available global
>>interchange format ( and could it be HTML / XML ? ), it will remain the
>>default. That doesn't mean that we should just accept it for evermore. If
>>that principle were followed, we would still be drawing on cave walls and
>>large red rock formations ( Ayres in Australia ! ), which are not very
>>transportable !
>>
>>One of the things that the IETF could, and in my opinion SHOULD, do it to
>>make its documents available in several presentation formats, not to say
>>languages. Yes, we would still need a master copy and format, which could
>>be ASCII, but other, more presentable formats, would make life easier for
>>many people. The ITU-T ( I'm sorry to mention it, but they have been doing
>>this for decades ) publishes its documents in three languages. If the IETF
>>is really working for the world, it should take a more global view and
>>consider a similar sort of policy. Don't we have a work stream on
>>internationalisation ?
>>
>>Of course, this sort of effort costs money - lots of it. That's why the
>>ITU-T charges for documents. If you want it free, you take the IETF
>>approach and get the inexpensive, ASCII, American language version.
thats why the ITU claims it charges. i think you overstate the
contrast. btw, as someone who has written documents in english english
for 20 years using ascii codes, i dont see your point about American
_language_ - coding for alhpabet doesnt necessarily code for language
(ever used greeklish?:-)
anyhow, the point about cost is good - basically, do people want to
think about a funding model for multi-lingual internet standards...?
worth a brief discussion (there are alternates to the ITU charging
model, clearly)
j.
