[idn] Versioning schemes (was: Which lanuages/scripts to reorder?)

[DougEwell2@cs.com]

In a message dated 2001-10-22 7:27:01 Pacific Daylight Time, 
Erik.Nordmark@eng.sun.com writes:

>  One issue with reordering that hasn't been put on the table
>  is that, as a process, I'm concerned that it might never complete.

This is indeed an important concern, and we need to look at this notion of 
versioning from a practical perspective.

Consider the GIF standard for graphic files, plain old garden-variety 
pictures.  The original GIF specification included a signature with a version 
number, so that new versions could be easily distinguished from old versions. 
 And in fact there was an original "GIF87a" standard and a "GIF89a" upgrade, 
which added things like transparency, interlacing, and multiple images.  
However, the presence of these two versions caused noticeable confusion in 
the marketplace, and despite the subsequent demand for further improvements 
to GIF (such as 24-bit color), there was never an upgrade beyond GIF89a, 
largely because of the versioning problems (as well as the well-known patent 
debacle).

The PNG (Portable Network Graphics) standard, invented to replace GIF, was 
designed with an even smarter versioning scheme.  The entire file format was 
built as a series of "blocks."  Each block was tagged to indicate whether it 
was essential or optional to the rendering of the image, and new blocks could 
be added with impunity, since processors would presumably be able to know 
which non-essential blocks could be safely ignored.  Yet, when the most 
obvious shortcoming of PNG was finally fixed (lack of support for multiple 
images), it was not added to the PNG format itself.  Rather, a new, related 
format (MNG) appeared, apparently because existing PNG processors had not in 
fact been built to handle new and unexpected blocks.

XML, possibly the most talked-about new file format in recent memory, has its 
own versioning scheme.  XML files are tagged in a prominent way with their 
version number.  But so far, all we have seen is version 1.0, despite some 
major improvements to XML (such as namespaces) and some non-trivial changes 
in the Unicode standard atop which XML is built.  The XML "Blueberry" 
proposal, which supports the latest changes in Unicode, has met with hot 
debate from those who fear that even a second version of XML would cause 
great instability to the XML standard.

Even Unicode/10646 is sometimes criticized (although usually by those who 
have much to learn) for its "ever-changing" nature, even though most of its 
changes consist of adding new characters.

The bottom line is that creating a new standard, such as the Lee reordering 
proposal, with an eye already cast toward version 1.1, version 2.0, etc. 
isn't as straightforward as it may seem.  There is the inherent instability 
of having two or more versions in the first place, and on top of that, there 
is the perception -- right or wrong -- of instability that has already 
delayed or stalled upgrades to standards like GIF, PNG, and XML.

Just something to think about before we decide that calling one version 
"zq--" and another version "uq--" will solve all the problems for software 
that has to perform IDN conversions.

-Doug Ewell
 Fullerton, California