ISO 646 alternate representation

[Randall Atkinson]

In article <keld.670872140 at dkuugin> keld at 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