The precision indicator either must be present in all mappings or in none of them. The indicator is a pipe symbol ‘|’ followed by a 0, 1, 2, 3, or 4 that has the following meaning:
"Reverse fallbacks" are technically similar, but the same Unicode character can be encoded twice in the codepage. ICU always uses reverse fallbacks at runtime.
A subset of the fallback mappings from Unicode is always used at runtime: Those that map private-use Unicode code points. Fallbacks from private-use code points are often introduced as replacements for previous roundtrip mappings for the same pair of codes. These replacements are used when a Unicode version assigns a new character that was previously mapped to that private-use code point. The mapping table is then changed to map the same codepage byte sequence to the new Unicode code point (as a new roundtrip) and the mapping from the old private-use code point to the same codepage code is preserved as a fallback.
A "good one-way" mapping is like a fallback, but ICU always uses "good one-way" mappings at runtime, regardless of the fallback API flag.
The idea is that fallbacks normally lose information,
such as mapping from a compatibility variant of a letter to the ASCII version;
however, fallbacks from PUA and reverse fallbacks are assumed to be for
"the same character", just an older code for it.
So the default behaviour for ICU is to use
"good one-way" mappings, "reverse fallback" mappings,
and "fallback" mappings from private-use-area code points, but
only to use normal "fallback" mappings if the setFallback API
has been used.
IBM customers have requested the ability
to use normal "fallback" mappings. At the current time, the only
solution open to them is to change the .ucm file (or create a variant)
and change the "|1" mappings to "|4" so that "fallback"
mappings become "good one-way" mappings.
A proposal to support fallbacks was submitted
a few years ago by Mike. https://www.ogf.org/pipermail/dfdl-wg/2011-November/001631.html.
It proposed adding new DFDL annotations to allow replacement characters
and fallback mappings to be specified. This was rejected as ICU already
provides this via the .ucm file. But no simpler alternative materialised,
and the resulting erratum only added dfdl:encodingErrorPolicy, which does
not handle fallbacks.
Given a) the precedent of existing IBM DFDL
and Daffodil behaviour which (should) match the ICU default, b) the orthogonality
of substitition characters (an error has occurred) and fallbacks (defined
mappings for a purpose), and b) an IBM recommendation not to switch on
fallbacks by default, it feels like we need a new property eg: dfdl:useEncodingFallbacks
'yes' | 'no'. Alternatives welcome. The names dfdl:encodingFallbackPolicy
or dfdl:encodingPrecisionPolicy are better, but then comes the problem
of finding meaningful enum values...
Also noted: The woridng for dfdl:encodingErrorPolicy
'replace' says: If 'replace' then any error when decoding characters
results in the insertion of the Unicode Replacement Character (U+FFFD)
as the replacement for that error. That is not strictly true, as the
same ICU page says: