If 'error' then a processing error occurs.
It is suggested that if a DFDL user wants to preserve information containing
data where the encodings have these kinds of errors, that they model such
data as xs:hexBinary, or as a xs:string, but using an encoding such as
iso-8859-1 which preserves all bytes.
The following specific situations involving UTF-16, UTF-16LE, and UTF-16BE do not cause an encoding error:
In all these cases the code-point becomes part of the DFDL Information Item for the string.
For Unparsing/Encoding Errors
The following are kinds of errors when unparsing characters:
1. no mapping provided by
the encoding specification.
2. not enough room to output
the entire encoding of the character (e.g., need 2 bytes for a DBCS, but
only 1 byte remains in the available length.
The behavior in these cases is controlled by dfdl:encodingErrorPolicy.
If the policy is 'error' then a processing error occurs.
If the policy is 'skip' then the character is skipped. No character is
encoded to be output for case 1, and no partial character is attempted
in case 2.
If the policy is 'replace' then the behavior is determined by the encoding
specification.
Each encoding has a replacement/substitution character specified by the
ICU. (These can be found conveniently in the ICU
Converter Explorer. This character is
substituted for the unmapped character or the character that has too large
an encoding.)
It is a processing error if it is not possible to output the replacement
character because there is not enough room for its representation.
It is a processing error if a character encoding does not provide a substitution/replacement
character definition and one is needed because of dfdl:encodingErrorPolicy='replace'.
(This would be rare, but could occur if a DFDL implementation allows many
encodings beyond the minimum set.)