From: Doug Ewell (email@example.com)
Date: Thu Mar 03 2005 - 02:16:00 CST
Peter Kirk <peterkirk at qaya dot org> wrote:
> ... But I find it hard to reconcile with the whole concept of a
> standard which is supposed to specify how text should be represented,
> as well as with Doug Ewell's definition of stability that "it does not
> change in a way that causes existing implementations or data to
to which Asmus Freytag <asmusf at ix dot netcom dot com> responded:
> As stated, that definition is clearly nonsense.
Okay, hold on a minute. I'm being quoted out of context. My original
"'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."
Since I wrote that on Tuesday, Peter Kirk has quoted it at least twice,
but *only the last part* -- not the part where I qualified it with "as
much as possible," and not the all-important part where this type of
practical stability is contrasted with absolute immutability.
My intent in writing this brief description of "stability" -- it is not
intended as a "definition" -- was to respond to Doug Ulist's question
about whether the need to check the latest version of the Unicode
Standard was "in keeping with the idea of Unicode being inalterable."
I believe the broad response I pulled out of my back pocket was
consistent with the notion of stability as applied to the Unicode
Standard, and is not "clearly nonsense." (I'm not sure if Asmus was
referring to my statement or the context in which Peter quoted it.)
Stability is not Boolean, and not absolute. It is not the case that a
standard is either stable and thus never changes, or changes and is thus
"Unicode" -- here I am deliberately being vague between the standard and
the standardizing body -- sometimes finds itself in a position where
absolute stability has to be weighed against the benefit of making a
change. One example of this is the normalization corrections. At some
point it is considered better to correct an error in the normalization
data than to allow the error to remain for the sake of stability. That
does not mean the UTC is not interested in stability, but that sometimes
there are other issues weighing against it and a hard decision has to be
On top of all this, we have a situation where people do not even agree
on what it means for existing implementations or data to "break."
Please don't take my back-pocket interpretation of "stability" and carve
it in stone. I don't speak for the Consortium, and certainly not for
the UTC (to which I don't belong). My idea of "stability" is mine
This archive was generated by hypermail 2.1.5 : Thu Mar 03 2005 - 02:18:57 CST