[jira] [Commented] (DAFFODIL-2792) choice in hidden group unexpected behavior

["Mike Beckerle (Jira)" <ji...@apache.org>]

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

Mike Beckerle commented on DAFFODIL-2792:
-----------------------------------------

[~jadams_tresys] FYI since you are looking at other choice-resolver/element-resolver issues. 

> choice in hidden group unexpected behavior
> ------------------------------------------
>
>                 Key: DAFFODIL-2792
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2792
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Middle "End"
>    Affects Versions: 3.4.0
>            Reporter: Mike Beckerle
>            Priority: Minor
>
> I'm not 100% certain this is a bug. 
> Given a choice like this:
> ```
> <group name="optionalLineEnding">
>   <choice>
>       <element name="zlString" type="xs:string" 
>              dfdl:lengthKind="explicit" dfdl:length="0" 
>             dfdl:outputValueCalc='\{ "" }'
>            dfdl:terminator="%NL;"/>
>       <sequence/>
> </choice>
> </group>
> ```
> When this is used as a hiddenGroupRef, my understanding is that the choice should default to the first choice branch, which is an element with an outputValueCalc, so should default to "" which is valid, Then unparse, which will output the terminator. 
> But what I am seeing instead is that it does not output anything. 
> If I replace the 2nd choice branch (the empty sequence) with a zero-length element, but one not having a terminator, then the behavior is as expected, when unparsing, the terminator is output.
> ```
>       <element name="zlString2" type="xs:string" 
>              dfdl:lengthKind="explicit" dfdl:length="0" 
>             dfdl:outputValueCalc='\{ "" }'/>
> ```
> With the empty sequence, this unparse is behaving as if the group was not hidden, since there is no <zlString/> element in the infoset, unparsing chooses the other branch that doesn't need there to be a zlString in the infoset; hence, not unparsing a zlString element and hence, no terminator is unparsed. 
> With the element zlString2, the unparse behaves as if it had to make a choice between zlString element, and zlString2 element, and since neither is in the infoset, it chooses the first choice branch because nothing is forcing it to select any specific choice branch, and so it picks the first, unparses that, and we get the terminator we want. 
> So, why this might not be a bug.
> Imagine we had two different uses of the group above. One is hidden, one is not. 
> There's only one implementation of the shared group. 
> So its behavior cannot be different depending on hidden or not. It has to do the same thing either way. 
> This is not the very last thing in the schema. There is more data after this terminator, and more elements in the infoset after this hidden group. 
> Hence, when compiling the schema, the choice branch determination is going to behave here as if the group was NOT hidden. It will choose the empty sequence when there is no zlString element in the infoset, regardless of the fact that the group is hidden, because it has to do the same thing hidden or not hidden.
> So, is this a bug? Do groups need to behave differently if hidden than not? 
> I believe it is a bug for anything to be expecting a zlString in the infoset for unparsing, and analysis in the optimizers of the compiler is faulty if it is treating this choice resolver situation the same, for hidden/not-hidden, as it must not be taking the fact that zlString is hidden into account. 
> So, by that reasoning, this is a bug. 
>  



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