Re: [Unicode Announcement] New Public Review Issues for Unicode 6.0 UAXes

From: Kenneth Whistler (
Date: Tue Mar 02 2010 - 12:13:56 CST

  • Next message: Asmus Freytag: "Re: [Unicode Announcement] New Public Review Issues for Unicode 6.0 UAXes"

    Doug Ewell asked:

    > > The Unicode Consortium is revising the Unicode Standard Annexes for
    > > eventual release of Unicode 6.0. A standard part of our development
    > > process is to open all of the annexes for public review.
    > I'm curious what the benefit is of creating a new revision of *all*
    > UAXs, including those which have not changed. I quickly scanned a
    > sample of four of the documents under review, and three of them (24, 29,
    > 34) have no change except for boilerplate and copyright date (sometimes
    > rendered as "20010," BTW). I know integers are cheap, but is this just
    > a matter of following protocol or is there another benefit?

    The UTC decided some time ago that it was less confusing to
    move forward the *entire* content of the Unicode Standard
    whenever a new version was required, rather than to attempt
    to specify a version as consisting of some hodge-podge of
    updated pieces plus some unchanged pieces from prior versions.

    This general policy applies both to the annexes (which are a
    part of the complete text of the Unicode Standard) and to
    the data files, which are also moved forward for each version
    as a complete batch, even for data files which otherwise
    have no individual required change for that version.

    To see what the UTC is attempting to avoid, look at the
    detailed definition of Version 3.0 of the Unicode Standard,
    available at:

    For Version 3.0 of the Unicode Standard, the annexes that
    existed at the time and their individual versions were:

    UAX #15, Version 18.0
    UAX #14, Version 6.0
    UAX #11, Version 5.0
    UAX #13, Version 5.0
    UAX #9, Version 6.0

    The data files had equally disparate version numbering, since
    at the time, they simply had their numbers bumped when they
    were actually changed.

    That situation proved confusing to people who were trying to
    determine the exact contents of the standard at any given
    verison level, despite the guidance given about the enumerated
    versions on the Unicode website.

    The current policy results in clearly labeled versions for
    all of the data files and all of the annexes -- versions
    which always match the version of the complete standard.

    The downside, of course, is that in some instances, particularly
    for the annexes, a new version may have no real content change.
    But the Modification history for each annex provides the relevant
    details that should help people determine when significant
    changes have occurred in an annex.

    Another thing you should know is that a number of the newly
    posted proposed updates for the annexes have content changes
    still planned for them. There are mandated fixes still in
    the works for UAX #14 and UAX #38, for example, which simply
    have not yet been integrated into the new proposed update
    drafts. Those will be noted in both the Public Review Issue
    items and in the Modification history of each document, as
    the relevant author(s) and the editorial committee can get
    them incorporated into the drafts. So not all of the drafts
    which currently include only version-related boilerplate
    updates will remain that way.

    Just procedurally, however, it is easier for the editorial
    committee to get the entire batch opened for public review
    before every last piece of intended content change is
    incorporated. And the UTC mandated that it happen that way.
    Among other things, having all the annexes open for public
    review for each version puts the general public on notice
    that feedback and review of their existing content is
    invited by the UTC, even in those cases where there is no
    specific change that has yet been required by a UTC decision
    for a particular document.


    This archive was generated by hypermail 2.1.5 : Tue Mar 02 2010 - 12:19:08 CST