Richard
On 5/23/2017 1:48 PM, Richard Wordingham via Unicode wrote:
The object is to generate code*now* that, up to say Unicode Version 23.0, can work out, from the UCD files DerivedAge.txt and PropertyValueAliases.txt, whether an arbitrary code point was included by some Unicode version identified by a Unicode version identified by a value of the property Age.
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.
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.
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 ... ;-)
What TUS 9.0, its appendices and annexes is lacking is a clear statement such as, "The short values for the Age property are of the form "m.n", with the first field corresponding to the major version, and the second field corresponding to the minor version. There is no need for a third version field, because new characters are never assigned in update versions of the standard."
I think the UTC and the editors had just been assuming that the pattern was so obvious that it needed no explaining. But the lack of a clear description of Age had become apparent, which is why I wrote that text to add to UAX #44 for the upcoming version.
Conveniently, this almost true statement is included in Section 5.14 of the proposed update to UAX#44 (in Draft 12 to be precise. It's not quite true, for there is also the short value NA for Unassigned. Is there any way of formally recording this oversight?
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.
--Ken
