Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!mcnc!uvaarpa!murdoch!usenet From: rja@altair.CHO.GE.COM (Randall Atkinson) Newsgroups: comp.std.c Subject: Re: ISO 646 alternate representation Message-ID: <1991Apr7.165616.12143@murdoch.acc.Virginia.EDU> Date: 7 Apr 91 16:56:16 GMT References: <1991Apr4.171657.27791@murdoch.acc.Virginia.EDU> Sender: usenet@murdoch.acc.Virginia.EDU Reply-To: rja@edison.cho.ge.com Followup-To: comp.std.c Organization: University of Virginia Lines: 63 In article keld@login.dkuug.dk (Keld J|rn Simonsen) writes: [ Randall Atkinson`s previous article text is preceded by %'s ] % However, all of western Europe is moving rapidly to the ISO 8859/1 % standard which has none of the ISO 646 problems at the source level % and moreover the trigraphs address the ISO 646 technical problem % (which I emphasise is a temporary problem already starting to fade). >Yes, it is fading, but slowly. I have recently been involved in >discussions about 8-bit SMTP and there many *Americans* said >that there will be a considerable amount of people over there >sticking to American 7-bit, on one or the other way. >The same is true here. I run on a 8-bit capable PC, but still run >the Danish 7-bit code, for various reasons. I hope to convert soon, tho. % The POLITICAL issue is coming from the Danes who feel that their % local character set standard based in ISO 646 should be the focus % of the whole world and that long standing C practice should be % broken to make them feel better. >It is not our local standard we want supported, but ISO 646 invariant, >which is an *international* standard, and the base for all national >ISO 646 standards. Actually, what Keld acknowledges above but conveniently ignores here is that the ISO 646 standard has been SUPERCEDED by the ISO 8859/* family of standards referred to above. There is no need for anything but trigraphs to support the temporary issue of ISO 646 that Keld acknolwedges is fading. Trigraphs are a sufficient solution and the Danish proposal will add incompatible permanent changes to resolve a very temporary problem. The folks at X3J11 were very careful to standardise existing practice and avoid all needless deviance from existing practice. The Danes however are proposing adding needless and potentially dangerous deviations. >>WG14 passed resolutions both ways depending on who had spoken more >>recently to the group, whether the history of the question at the >>X3J11 level and the history of the C language was presented, >>and also some political grounds. The Danes ignored the WG14 decisions >>against them and then turn around and accuse X3J11 of being indifferent >>for their insistence on sticking to technical merit rather than >>political issues. > >WG14 only let us down once, and that was after X3J11 ignoring WG14 >resolutions for a long period, and after X3J11 at a combined meeting >made it clear that they were very reluctant in implementing the WG14 >resolutions. WG14 are now fully behind this Danish requirement. What Keld ignores is that on the occasions when WG14 has sided with the Danes, there was inadequate representation of the history of X3J11's decisions and rationale to WG14. At the only hearing where that was present, WG14 supported X3J11 after hearing both arguments. I hear far too much dissent from other folks on WG14 for the claim "fully behind" to be accurate. Keld still has never posted any definitive TECHNICAL description of the Danish "problem" on this list and I think that if he is going to continue to raise this "problem" here that he should post a full and complete technical problem statement here for further discussion by all. Randall Atkinson