[ 
https://issues.apache.org/jira/browse/DAFFODIL-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697040#comment-17697040
 ] 

Steve Lawrence commented on DAFFODIL-2158:
------------------------------------------

In EvTextNumber, we make these calls on the DecimalFormat when the primitive 
type is an integer:

{code:scala}
df.setMaximumFractionDigits(0)
df.setDecimalSeparatorAlwaysShown(false)
df.setParseIntegerOnly(true)
{code}

I think this basically makes it so when parsing ICU will fail if there are any 
decimal digits. And I guess on unparsing it drops any decimal digits?

Maybe we just need to remove these lines so that both parse and unparse use the 
text number pattern, which would allow fractional parts?

This does mean that df.parse(...) could return a non-zero fractional part for 
integer types, which I think we currently assume can never happen. I guess we 
would also want to add a check that the fractional part of parsed integers and 
infoset integers is zero, or it should be a parse/unparse error?

> textNumberPattern not being used for xs:int ?
> ---------------------------------------------
>
>                 Key: DAFFODIL-2158
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2158
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Back End
>    Affects Versions: 2.4.0
>            Reporter: Mike Beckerle
>            Priority: Critical
>             Fix For: 3.5.0
>
>
> Look at the DFDLSchemas/MagVar project.
> In that schema, which is siimple fixed-length data, there are columns of 
> integers (xs:int) and of floats.
> The textNumberPattern *was* "###0.0###;-###0.0###".
> When I tested this for portability with IBM DFDL, it errored because the 
> xs:int elements were unparsing as 0.0, 1.0, not just 0, or 1.  One of the 
> integer columns is only 2 characters wide, so even 0.0 doesn't fit and was 
> giving a runtime error.
> So I had to introduce a separate named DFDL format so that the integer 
> elements and the float elements could have different textNumberPattern 
> values, because the integers need "###0.###;-###0.###", the floats need the 
> pattern above to work right.
> So now it works portably.
> But.... why didn't Daffodil unparse the integers as 0.0, 1.0, and so forth 
> the way IBM DFDL did? It seems Daffodil is somehow not using the 
> textNumberPattern for these integers.
> And that seems like a bug to me.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to