Re: Comparing Raw Values of the Age Property

On Tue, 23 May 2017 17:44:49 -0700
Ken Whistler via Unicode <unicode_at_unicode.org> wrote:
 
> Ah, but keep in mind, if projecting out to Version 23.0 (in the year
> 2030, by our current schedule), there is a significant chance that
> particular UCD data files may have morphed into something entirely
> different. Recall how at one point Unihan.txt morphed into Unihan.zip
> with multiple subpart files. Even though the maintainers of the UCD
> data files do our best to maintain them to be as stable as possible,
> their content and sometimes their formats do morph gradually from
> release to release. Just don't expect *any* parser to be completely
> forward proofed against what *might* happen in the UCD in some future
> version.

So long as the parser chokes on the new input, that is not too bad for
my programs, which rely on being directed to a local copy of the
UCD. That issue would be nastier for any program that tries to keep
abreast of Unicode additions by downloading the relevant parts of the
UCD.

> On the other hand, for the property Age, even in the absence of
> normative definitions of invariants for the property values, given
> recent practice, it is pretty damn safe to assume:

> A. Major versions will continue to have two digits, incremented by
> one for each subsequent version: 10, 11, 12, ... 99.
> B. Minor versions will mostly (if not entirely) consist of the value
> "0", and will never require two digits.

> Assumption A will get you through this century, which by my
> estimation should well exceed the lifetime of any code you might be
> writing now that depends on it.

Yes, but
http://www.thejokeshop.org/2008/12/as-useful-as-a-cobol-programmer/ .

> BTW, unlike many actual products, the version numbering of the
> Unicode Standard is not really driven by marketing concerns. So there
> is very little chance of some version sequence for Unicode that ends
> up fitting a pattern like: 3.0, 3.1, 95 or NT, 98, 2000, XP, Vista,
> 7, 8, 8.1, 10 ... ;-)

The risk I saw was that someone would decide to deprecate value names
that look like floating point numbers, so that the relevant value for
Version 17.0.0 would be named V17_0 and have no aliases.

The new text in UAX#14 is also proof against the major version numbers
suddenly becoming the year numbers, as has happened with several
products.

> Yes. You could always file another piece of feedback using the
> contact form. However, in this case, you already have the attention
> of the editors of UAX #44. So my advice would be to simply wait now
> for the publication of Version 10.0 of UAX #44 around the 3rd week of
> June.

What deterred me was:
(a) "The beta review period for Unicode 10.0 and
related technical standards will close on May 1, 2017. This is the last
opportunity for technical comments before version 10.0 is released in
Q2 2017." -
http://blog.unicode.org/2017/04/last-call-on-unicode-100-beta-review.html

and

(b) Proposed changes aren't yet part of the Unicode standard.

Richard.
Received on Wed May 24 2017 - 00:22:40 CDT