Re: Still can't work out whats a "canonical decomp" vs a "compatibility decomp"

From: Asmus Freytag (
Date: Wed May 07 2003 - 19:14:00 EDT

  • Next message: Kenneth Whistler: "Re: Still can't work out whats a "canonical decomp" vs a "compatibility decomp""

    At 05:56 PM 5/7/03 -0400, you wrote:
    > > Actually, that describes the ideal - in the historic process of creating
    > > and maintaining these decompositions, that ideal has been compromised.
    >Fair enough. But it does describe what the original poster wanted to know
    >about: the *purpose* of having two different decomposition systems.

    Granted. The problem is that experience has shown a discrepancy between
    their stated purpose and their practical effect - magnified by their status
    as being practically immutable properties. (For more on different types of
    properties see

    > > The canonical decompositions were applied to CJK compatibility characters,
    > > essentially negating their purpose, and causing big practical problems in
    > > all environments where they are used. It's arguable that they should have
    > > been made compatibility decompositions.
    >They are a mixed lot, though; the Korean ones on the BMP are really, really
    >just clones, AFAIU.

    There's a difference between the case of A WITH RING and A + RING ABOVE,
    where we have no source that we expect to ever contrastively use BOTH. (And
    in Unicode, we wisely explicitly do not support constrastive use in

    This is different from the CJK (and other such duplications) where it's
    possible for the same source to use BOTH codes (with in some ways unknown
    purposes for contrasting them). By making such duplications canonical
    decompositions of each other, we invalidate the reason for having duplications.

    It might well be that a conclusion that declares contrastive use of the CJK
    duplicates to be not supported in interchange is correct for some of them.
    However, this position becomes hypocritical as we are both *adding* more of
    the CJK compatibility ideographs and at the same time experience a global
    change of information technology towards more distributed applications,
    where avoiding interchange, or even controlling when interchange happens,
    becomes rapidly more illusory.

    Both our external environment and our practical experience with the use and
    effect of decompositions has expanded since they were designed nearly 10
    years ago. It's time to take the consequences. If the existing
    decompositions are essentially frozen (and I agree that they must be), that
    means adding additional properties, so implementers can get back a clear
    set of mappings that are graduated by their effect and suitable context of


    This archive was generated by hypermail 2.1.5 : Wed May 07 2003 - 20:09:42 EDT