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

Steve Lawrence commented on DAFFODIL-2802:
------------------------------------------

I noticed that the TDML test sill fails if I change the unparserTestCases to 
parserTestCases. It seems Daffodil doesn't like trying to parse an empty string 
as an int for the ie3 element. Maybe this is correct? I wonder if this is 
because int's can't really have an empty representation like strings/hexBinary 
can? If I change ie3 to a string, then all tests work as expected. The one 
difference is that ie3 shows up in the infoset with an empty string value 
instead of being removed from the infoset. Makes me wonder if maybe this tdml 
test isn't totally accurate to the issue with real format? This bug still might 
be an issue, but it's possible fixing this won't fix the data format also.

> Array with optional element followed by scalar optional element drops 
> separator
> -------------------------------------------------------------------------------
>
>                 Key: DAFFODIL-2802
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2802
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Back End
>    Affects Versions: 3.4.0
>            Reporter: Olabusayo Kilo
>            Priority: Blocker
>             Fix For: 3.5.0
>
>         Attachments: TestSeparatorSuppression.scala, suppressedseparator.tdml
>
>
> An array with a trailing optional element followed by a scalar optional 
> element loses a separator when both elements are missing during an unparse. 
> The trace indicates, there's a 
> SuppressableSeparatorUnparserSuspendableOperation for the scalar element (se5 
> in the example schema). My initial guess was that the last element in the 
> array was being treated as a trailing element, but we need it to not be 
> treated that way.
>  
> For completeness, you get the following error from TDML on the 2nd test
> {noformat}
> output data length 12 for '/1/2/3.5//6
> ' doesn't match expected length 13 for '/1/2/3.5///6
> '{noformat}



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

Reply via email to