Mark Davis ☕ wrote:
> the analogy to the existing such policies seems strained at best.
> In practice this is what we do. I just don't think we need more rules.
There are many such policies:
see http://www.unicode.org/policies/stability_policy.html#Property_Value (or
the more
accessible http://www.unicode.org/policies/property_value_stability_table.html)
<http://www.unicode.org/policies/stability_policy.html#Property_Value>The
policies are vital; their purpose is to ensure that programmers know
what they can depend on in their implementations from version to
version, and what they can't. There are many, many 'accidental'
relationships between Unicode character properties that happen to be
true at this point in time, but which the consortium has no commitment
to maintain in future versions. On that page, and others
like http://www.unicode.org/policies/locales_stability.html, are the
relationships that programmers can depend upon, and build into their
implementations without fear that they many change across versions. See
also the new proposal for http://www.unicode.org/review/#pri173
Karl,
While it has been a good discussion, if you want to make a proposal for
such a policy you'll want to propose it to the UTC, using the feedback
form at http://www.unicode.org/reporting.html. (Posting to this list
doesn't suffice.) If the UTC decides to approve it then formally it
would then recommend adoption to the Unicode officers.
I would only go through with the effort to do that if it would do some
good, for example even if rejected, it would cause people to permanently
keep the idea that a zero code point need be reserved to account for
evolving usage during the life of the standard.
I've gotten mixed messages about this from various responders. From my
perspective, the most useful to me was Asmus saying that for practical
purposes, I need not worry about future violations. Thus, I don't care
if there is a formal rule or not. I think, though, that the guidelines
should be written down in an appropriate place so that they don't get
forgotten.
As far as the formulation, rather than:
"New scripts or forms (like mathematical mono space) that have
decimal numbers will be assigned so that those decimal numbers
occupy at least 10 contiguous code points such that the code point
for DIGIT ONE = 1 + the code point for DIGIT ZERO, etc."
The end result would probably be phrased as a relationship between the
properties Numeric_Type and Numeric_Value, not what can be encoded
where, perhaps something like:
For each character with Numeric_Type = Decimal (nv=de) and
Numeric_Value = N: if N > 0 then the preceding character (in code
point order) has nv=de and nv=(N - 1); if N < 9 then the following
character has nv=de and nv=(N + 1).
There would, of course, be implications for allocation, like for other
policies.
Hope this helps,
Mark
/— Il meglio è l’inimico del bene —/
On Mon, Jul 26, 2010 at 06:55, John Burger <[email protected]
<mailto:[email protected]>> wrote:
Mark Davis ☕ wrote:
>From just a quick scan, it appears that they are currently all
contiguous within their respective groups. If we were to impose
a stability policy, it would be a constraint on the
general_category: we would not assign
general_category=decimal_number to any character unless it was
part of a contiguous range of 10 such characters with ascending
values from 0..9.
Whether such a policy makes sense, I'm not clear on why it would be
called a "stability" policy - the analogy to the existing such
policies seems strained at best.
- John D. Burger
MITRE
