L2/13-005

Title: Feasibility of Accelerated Releases for a Small Repertoire

Author: Ken Whistler

Date: January 16, 2013

I have an action item (AI 131-A12) to look into the feasibility of
designing a mechanism for accelerated releases for a small repertoire
of urgently required characters (e.g. a currency sign). In some
regards this action item is moot, because recently we just complete
such an accelerated release (Unicode 6.2) for the Turkish lira sign.
So there already is an existence proof. Furthermore, we are currently
mid-stream in the next release (Unicode 6.3), which is also a somewhat
accelerated release including a very small additional repertoire of
urgently required characters – the 4 new bidi format controls.

However, to close the loop on this, I want to spell out what the
editorial committee has generally concluded is and is not feasible for
such an accelerated release with a very small repertoire addition, to
help guide UTC decisions about any future such releases.

First, it is simply not feasible to attempt short cuts regarding the
character property data for a Unicode release in the Unicode Character
Database. Too many implementations depend on formal completeness and
consistency of the UCD data files. An attempt to do a small data delta
for the UCD would just introduce confusion, a permanent discontinuity,
and complexity into the data part of a release. It would be unlikely
to save any time or resources in the long run. Furthermore, for the
data release, it would be inadvisable to skip our current process of a
beta review cycle between UTC meetings. Even if the addition of a
character and its properties seems to involve obvious changes, it
still makes sense to let implementers test it out with a full data set
before the UTC commits to its final, permanent release in a version of
the standard. Note that this also applies to the changes for the UCA
and its data files, which under our current process also have to be
updated at the same time as a version of the Unicode Standard.

On the other hand, the addition of a small additional repertoire, such
as a single currency sign, generally does not involve much, if any,
textual impact on the Core Specification. Because of this, the
editorial committee recommends that for an accelerated release for a
small repertoire of urgently required characters, it makes sense to
omit the updating of the full Core Specification. Instead, the web
landing page for that version of the standard can simply make clear
the delta in the formal version reference for the standard, but
otherwise point to the existing Core Specification pages from the
previous version of the standard. This is the plan of action, in fact,
for the Unicode 6.3 release which is currently underway. On the other
hand, this option is not available for updates to the standard which
involve large repertoire additions, including entire scripts, because
those additions *do* require modifications to the Core Specification,
often in ways that are fairly substantial.

The UAXes occupy an intermediate ground. All of the annexes are
currently updated for every version of the Unicode Standard. This is
done, in part, because, the former regime in which all parts of the
standard did not self-identify their version, and in which Version
x.y.z of the Unicode Standard included by reference Revision m of UAX
#9, Revision n of UAX #15, and so forth, just proved to be too
confusing for people. Because there are now *13* UAXes associated with
the Unicode Standard, this requirement to update all of them for each
release of the standard involves a fair amount of documentary
bookkeeping, even when there is no substantive change to the content
of an annex. However, the updating is by now a fairly routine and rote
process, as long as there are no other changes, and the editorial
committee has a process in place to handle it.

Because the editorial effort (and the resources involved) scales up
pretty quickly for annexes, depending on the amount of change required
by the UTC for any particular document for a release, the
recommendation of the editorial committee is as follows: If there is a
requirement for an accelerated release of the Unicode Standard, to
include just a single new currency sign, for example, then as far as
possible, content changes for the annexes should be postponed for a
subsequent release. This mechanism is, in part, how we handled Unicode
6.2. The substantial changes for UBA in UAX #9 were postponed, to what
is now planned as Unicode 6.3, so that the work on them would not hold
up the release of the Turkish lira sign in Unicode 6.2.

Note that all of these recommendations also assume that any
accelerated release involving a small repertoire addition can be done
in an interim during which the Unicode Standard will not be exactly in
synch with any published addition to ISO/IEC 10646. There will be an
implicit promise involved that such asynchronization is temporary, and
that in some future, major version, the UTC will endeavor to resynch
with a published edition of 10646. It would not be a good idea to
start down the road of permanently picking and choosing just some
priority repertoire to move forward on, while indefinitely postponing
other content approved in amendments to 10646. To do so would
destabilize the standing relationship between the two standards and
would also risk confusion and opposition in various arenas.