From: Asmus Freytag (firstname.lastname@example.org)
Date: Thu Mar 03 2005 - 13:13:09 CST
At 10:30 AM 3/3/2005, Jeroen Ruigrok/asmodai wrote:
>-On [20050302 05:22], Doug Ewell (email@example.com) wrote:
> >"Stability" in a standard does not mean that the standard never changes.
> >It means that, as much as possible, it does not change in a way that
> >causes existing implementations or data to break.
>I hope I am not asking a FAQ here, but what about major release numbers?
>Say from 3.x to 4.x, does that allow the Unicode standard to break
>compatibility in some ways?
You are asking an excellent question, which addresses a perspective that is
certainly motivate by the types of expierence you cite:
>Because, working too much on ABI/API versioning, I know that if you don't
>clean up completely every once in a while the entirety of backwards
>compatibility might sound nice from a certain perspective it will also be a
>ball and chain grinding you to a slow and painful halt where discussion
>about backwards compatibility will be the brunt of the discussion instead of
>getting a lean technology standard.
The answer is threefold:
On the first level, there is nothing special about major versions and
On the second level, Unicode describes how to encode content. Unlike
software, data rarely (if ever) gets updated once it exists. Requiring
existing data to be updated would effectively mean to abandon it to
inaccessibility after a few years. That's totally contrary to Unicode's aims.
On the third level, there may be a time, sometime in the mists of the
future, when it's time to start over. In terms of Unicode that would be
whenever there's enough reason and momentum behind a successor standard.
However, as we have seen when we created the Unicode Standard,
existing character sets have a way of forcing a new standard to be
compatible, lest it be a non-starter. The same pressure, magnified, would
face any successor standard to the Unicode Standard.
This archive was generated by hypermail 2.1.5 : Thu Mar 03 2005 - 13:14:19 CST