more flexible pipeline for new scripts and characters

From: Peter Cyrus <pcyrus_at_alivox.net>
Date: Wed, 16 Nov 2011 14:15:05 +0100

I've only been on this list for some months, and I only came to it with my
own little project in mind, but it occurs to me, as I follow all these
threads, that Unicode might benefit from a more flexible process of
adaptation, of Unicodification. The model would be an asymptotic approach
to standardization that tolerated an amount of change in inverse proportion
to time elapsed.

In other words, people could propose a new script or character and rather
than have it discussed before encoding and then encoded in permanence, with
no possibility even to correct obvious errors as in U+FE18, instead it
would be provisionally accepted but still subject to modifications as
implementors worked with it. Hopefully, most mistakes would be unearthed
early and corrections applied before much text had been encoded. As time
passed and the encoding became more stable, the size of mistake open to
correction would be reduced, e.g. to spelling errors, until it was frozen
as a result of this process before being declared permanent.

My thought is that some of the problems that I've seen discussed might have
been discovered and addressed had a community been using the proposed
standard before it became immutable. In the current process, that
transition may occur too early to be useful. It may be easier to fix all
the existing text if very little time has passed, than to "fix" all future
text forever.

This idea could also be extended to new characters and scripts that might
or might not make it into Unicode : Unicode could offer a provisional
acceptance that allowed users to demonstrate the utility of the proposed
changes once they're in Unicode, even if they're later modified or
withdrawn. This policy might have prevented the recoding of Tengwar,
Cirth, Shavian, Phaistos Disc and Deseret as they moved from the PUA to the
SMP.

It seems to me that the current policy is intended to offer implementors a
guarantee of our best effort to save them the trouble of chasing down
problems, but in fact they might prefer to have some problems fixed early
(while the developers still remember the application) than to have to take
unfixed problems into account forever.

This idea is WAY beyond my expertise, but I thought I'd mention it for you
all to consider.
Received on Wed Nov 16 2011 - 07:19:14 CST

This archive was generated by hypermail 2.2.0 : Wed Nov 16 2011 - 07:19:15 CST