From: verdy_p (verdy_p@wanadoo.fr)
Date: Thu Jul 09 2009 - 08:12:55 CDT
May be we could think about creating new properties designed so that their values are considered "current best
practices" rather than mandatory. I.e. properties containing corrected values.
They would escape the stability policy rule (because this would be separate properties). Newer implementations could
consider these corrections as being acceptable rather than rejecting their associated bahavior when using only the
stable property. This would work for most stable properties (except those used for implementing the standardized
normalisation algorithms NF(K)C/D), such as the alternate (more descriptive and less confusive) character name (may
be an additional comment property giving usage hints).
The UCD is really missing important data or comments that were considered within discussions (prior to the character
encoding, or when other new similar characters were added later). This causes this list to repetedly discuss the
same issues for some characters, when there are commonly accepted usage hints to show the effective differences, or
specific usages in some languages.
Additionally, the UCD still does not contain any data about the characters that are considered unified/equivalent
within some wellknown languages, or about characters that were added later only to allow distinctions for a few or
just one specific language(s); it's true that characters are not encoded specifically for some languages, but in
many cases, the fact that new characters are added will not change the fact that existing languages that were using
older characters will continue to use them preferably or equivalently: other languages may use one or several other
characters and not the new one that were added later (in fact we have a hint about this, which is the character's
age, i.e. the version from which each character was added)
> Message du 09/07/09 07:52
> De : "Phillips, Addison"
> A : "karl williamson"
, "unicode@unicode.org"
> Copie à :
> Objet : RE: Property stability policy considered harmful
>
>
> What the policy guarantees is that implementations that rely on a particular property name or value being valid
will not suddenly find that they specify values that are not legal property names or property values. A negative
counter-example prompting this policy was the change of the script value 'Greek' to 'Greek_and_Coptic".
>
> This is an important guarantee, independent of whether a given property name or property value is currently in use
or which set of code points (including the empty set) is assigned particular name-value pairings. Certainly
implementations of UTS#18 (regular expressions) rely on it, as do such things as XML Schema 1.1.
>
> You are right that implementations may still struggle with formerly useful property names or values now being
essentially useless. But your code will still work according to the current expectations of the current version of
Unicode. Other stability policies might be worth examining, but they are orthogonal to whether names or values can
be respelled at a later date.
>
> Addison
>
> Addison Phillips
> Globalization Architect -- Lab126
> Chair -- W3C Internationalization WG
>
> Internationalization is not a feature.
> It is an architecture.
>
> > -----Original Message-----
> > From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org]
> > On Behalf Of karl williamson
> > Sent: Wednesday, July 08, 2009 4:02 PM
> > To: unicode@unicode.org
> > Subject: Property stability policy considered harmful
> >
> > It appears to me that the stability guarantees that a property and
> > property value alias will never be removed are worse than not
> > having
> > them. And the reason is that all code points they contain can
> > simply be
> > moved to another property (or property value) without violating the
> > letter of the policy. This has happened with
> > Script=Katakana_Or_Hiragana whose contents were all moved to Common
> > in
> > 4.1, and it appears to be happening in 5.2 with ISO_Comment. If I
> > have
> > a program that is looking for a property that has become empty, I
> > would
> > rather know about it at compilation time rather than to have it go
> > along
> > and give wrong answers (perhaps subtly so).
>
>
>
>
>
This archive was generated by hypermail 2.1.5 : Thu Jul 09 2009 - 09:21:08 CDT