From: Donn Terry <yyyy@xxxxxxxxxxx>
yyyyyyyyyyyyyyy@xxxxxx wrote:
>
> Donn Terry (mailto:yyyy@xxxxxxxxxxx) writes:
>
> @ Page 7 Line 171 Section 2.16 Comment []
>
> Problem:
> Are all the character names (this is just the first one I noticed)
> in complete correspondence with the corresponding ISO standards? If
> so, say so somewhere. If not, they will need to be before the
standard
> can be approved for ISO.
>
> Action:
> (Presumably someone just knows which is true): fix as noted.
>
> What would be the corresponding ISO standards? ISO 2022? ISO 4873? ISO
8859-1?
> No, the terminology is not the same as the one used in such
> standards, but it would be unwise to try to change this
> state of affairs, I think.
>...
The point here is that character sets are already a confusing mess; the
introduction of additional definitions that are not in complete accordance
with ISO standards just adds to the confusion. Presumably the definitions
ARE in accordance in spirit with 646 (they certainly were in .1, but these
came from .2 and I didn't check that side as carefully). The question was
if they are in accordance with the letter. (Note: I don't have an objection
to additional names for existing characters (e.g. dot, period), as long as
we never end up implying that in a character set that COULD distinguish
the two (e.g. 10646 might) that they are allowed to be different codes.)
Yes, but I am not sure I made my point clear.
My point is that the present draft standard uses a terminology
that is *very* different from ISO character standard terminology.
I think it is a major project (and, IMO, a pointless project)
to rewrite the present draft so as to conform in terminology
with the terminology from ISO character set standards.
Moreover, most other ISO standards do not conform either,
so it is impossible to construe this as a requirement
for the current draft to be eligible for becoming an ISO standard.
Andries
|