Re: more flexible pipeline for new scripts and characters

I guess what I'm proposing is that the proposed allocations be implemented,
so that problems may be unearthed, even as the users accept that the
standard is still only provisional.

On Wed, Nov 16, 2011 at 3:25 PM, Asmus Freytag <asmusf_at_ix.netcom.com> wrote:

> Peter,
>
> in principle, the idea of a provisional status is a useful concept
> whenever one wants to "publish" something based on potentially doubtful or
> possibly incomplete information. And you are correct, that, in principle,
> such an approach could be most useful whenever there's no possibility of
> correcting some decision taking in standardization.
>
> Unicode knows the concept of a provisional property, which works roughly
> in the manner you suggested. However, for certain types of information to
> be standardized, in particular the code allocation and character names, it
> would be rather problematic to have extended provisional status. The reason
> is that once something is exposed in an implementation, it enables users to
> create documents. These documents would all have to be "provisional",
> because they would become obsolete once a final (corrected or improved)
> code allocation were made.
>
> The whole reason that some aspects of character encoding are "write once"
> (can never be changed) is to prevent such obsolete data in documents.
>
> Therefore, the only practical way is that of having a bright line between
> proposed allocations (that are not implemented and are under discussion)
> and final, published allocations that anyone may use. Instead of a
> provisional status, the answer would seem to lie in making the details of
> proposed allocations more accessible for review during the period where
> they are under consideration and balloting in the standardization committee.
>
> One possible way to do that would be to make repertoire additions subject
> to the "Public Review" process.
>
> Another would be for more interested people to become members and to
> follow submissions as soon as they hit the Unicode document registry.
>
> The former is much more labor-intensive and I suspect not something the
> Consortium could easily manage with the existing funding and resources. The
> latter would have the incidental benefit of adding to the funding for the
> work of the Consortium by providing some additional funding via from
> membership fees.
>
> A./
>
Received on Wed Nov 16 2011 - 08:40:59 CST