* Do you only have the dfdl:encoding property on the root csv element? In
that case, the encoding property only affects the csv element, and not any
other elements, including its children.
Ah! I was assuming the scope of the dfdl:encoding property was the csv element
and all its children. Kind of strange that that’s not the case.
* So either you need to add dfdl:encoding="{ $fieldencoding }" to the field
elements, or probably easier, add encoding="{ $fieldencoding }" to your
dfdl:format element to make the encoding variable apply globally to the entire
schema.
I did the latter and now it’s working as you described. Thanks Steve!
/Roger
-----Original Message-----
From: Steve Lawrence <[email protected]>
Sent: Saturday, November 23, 2019 8:42 AM
To: [email protected]
Subject: [EXT] Re: Bug in Daffodil - encoding property ignored
Do you only have the dfdl:encoding property on the root csv element? In that
case, the encoding property only affects the csv element, and not any other
elements, including its children.
Without the dfdl:encoding property set on the field elements, they will get the
encoding from the dfdl:format element, which I'd guess is UTF-8, and give the
behavior you're seeing.
So either you need to add dfdl:encoding="{ $fieldencoding }" to the field
elements, or probably easier, add encoding="{ $fieldencoding }" to your
dfdl:format element to make the encoding variable apply globally to the entire
schema.
Also, the dfdl:encodingErrorPolicy determines the behavior of Daffodil when
there's an encoding problem. Unfortunately, Daffodil currently only supports
"replace" and not "error". So if there is an encoding problem like you expect,
Daffodil will just replace the bad character with the unicode replacement
character. So you'll actually get something like this:
<field>Citro n</field>
That will unparse to "Citro?n" in an ASCII encoding.
On 11/23/19 8:07 AM, Costello, Roger L. wrote:
> See below for description of bug. Is there a workaround? /Roger
>
