The separator is ambiguous: "The delimiters '/' or '|' are used to separate alternative values..."

I haven't looked at it. If it's ambiguous or otherwise problematic, do you want to report it? Via a PAG issue?

The separator is ambiguous: "The delimiters '/' or '|' are used to separate alternative values..."

I haven't looked at it. If it's ambiguous or otherwise problematic, do you want to report it? Via a PAG issue?

Add for the next PAG discussion? I was more worried about the composed vs decomposed characters for the syntax.

Add for the next PAG discussion?

yes, asap given the timing and holidays/vacations

I was more worried about the composed vs decomposed characters for the syntax.

I didn't quite understand the problem. Usually a composite of letter+mark is also a letter.
Can you give an example from spec & data where you think there is a problem?

Hi Markus:
Compare the syntax for:

• https://www.unicode.org/reports/tr57/#kEH_FVal
• https://www.unicode.org/reports/tr57/proposed.html#kEH_FVal

Then compare those to U+13002 kEH_FVal ḥmsꞽ from [Unikemet.txt]https://www.unicode.org/Public/UCD/latest/ucd/Unikemet.txt).

The ḥ (U+1E25) from the first char of kEH_FVal for cp 13002 is specified in https://www.unicode.org/reports/tr57/#kEH_FVal, and would be covered by h combined with \x{323} from https://www.unicode.org/reports/tr57/proposed.html#kEH_FVal
However, I've tried the syntax with two different regular expression tools and neither of them match ḥ on [h\x{323}]+.

So, the problem is that the syntax makes sense for humans, but not for (at least) some parsers.

The spec says

All data in the Unikemet database is stored in UTF-8 using Normalization Form C (NFC). Note, however, that the “Syntax” descriptions below, used for validation of property values, operate on Normalization Form D (NFD), primarily because that makes the regular expressions simpler.

I think that means that for validation you have to normalize the values to NFD and then run the regexes. But I would expect UCDXML to store the original values (in NFC form) just like Unikemet.txt.

Do we make that caveat in any other UAX?

Do we make that caveat in any other UAX?

Same wording in UAX38: https://www.unicode.org/reports/tr38/#DatabaseDesign

I haven't checked others.