This was not a problem for UCDXML as that one parses the file independently,

Will UCDXML be able to call the regular Unicode Tools functions after this, rather than parsing it independently?

Will UCDXML be able to call the regular Unicode Tools functions after this, rather than parsing it independently?

That is a question for @jowilco, but of course I would like to minimize the number of UCD parsers we spawn here…

Will UCDXML be able to call the regular Unicode Tools functions after this, rather than parsing it independently?

That is a question for @jowilco, but of course I would like to minimize the number of UCD parsers we spawn here…

@markusicu , @eggrobin
In theory, yes I could read the values using IndexUnicodeProperties.getResolvedValue(UcdProperty.normalization_correction_*, codepoint), however;

1. There are only 6 code points, and I don't "know" what these are without a source of truth (like parsing NormalizationCorrections.txt). Parsing NormalizationCorrections.txt would put me back where I am now. Obviously, I could run the full 0x0-0x10FFFF range, but...
2. The <normalization-corrections> section of UCDXML is separated from the main <repertoire> section. There are comparable sections for <blocks>, <named-sequences>, etc. All of these sections are implemented by parsing the corresponding source file. Most of them are not single code point -> value(s). I'm therefore not sure it makes too much sense in implementing a different path for <normalization-corrections> just so I can use IndexUnicodeProperties.

I'm therefore not sure it makes too much sense in implementing a different path for just so I can use IndexUnicodeProperties.

Fair point. Effectively, it would mean removing one parser, but adding something equivalent to MakeUnicodeFiles (the UCD file generator), and that way madness also lies.