From: karl williamson (public@khwilliamson.com)
Date: Mon Jul 26 2010 - 21:35:31 CDT
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 <john@mitre.org
> <mailto:john@mitre.org>> 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
>
>
This archive was generated by hypermail 2.1.5 : Mon Jul 26 2010 - 21:37:43 CDT