[
https://issues.apache.org/jira/browse/DAFFODIL-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691299#comment-17691299
]
Steve Lawrence commented on DAFFODIL-2324:
------------------------------------------
At the core, this is an unparse issue, so changing your tests to be
unparseTestCases will likely make it easier to reproduce.
It will also probably be easier if you change the empty/notEmpty elements to
output different values instead of the empty string, e.g.
dfdl:outputValueCalc="\{ '0' }" and dfdl:ouputValueCalc="\{ '1' }". That way,
when daffodil picks a branch to unparse, it will unparse a zero or a one
depending on which branch it chose.
Also, the first/secondChoice inputValueCals aren't evaluated on unparse, so
they really don't help determine if empty/nontEmpty exists (hence the idea to
outputValueCalc 0 or 1). We can just remove those elements.
We can also remove remainder element since I don't think it is needed.
Here's a simplified schema that I think triggers the same issue:
{code:xml}
<group name="empty">
<sequence>
<element name="empty" type="xs:string" dfdl:lengthKind="explicit"
dfdl:length="1"
dfdl:outputValueCalc="{ '0' }"/>
</sequence>
</group>
<group name="notEmpty">
<sequence>
<element name="notEmpty" type="xs:string" dfdl:lengthKind="explicit"
dfdl:length="1"
dfdl:outputValueCalc="{ '1' }"/>
</sequence>
</group>
<element name="emptyFirst" dfdl:lengthKind="implicit">
<complexType>
<sequence>
<choice>
<sequence dfdl:hiddenGroupRef="ex:empty" />
<sequence>
<sequence dfdl:hiddenGroupRef="ex:notEmpty" />
<element name="foo" type="xs:string" minOccurs="0"
dfdl:lengthKind="explicit" dfdl:length="1"/>
</sequence>
</choice>
</sequence>
</complexType>
</element> {code}
And something similar for emptySecond.
If your input infoset contains a <foo /> element, then it will always unparse
with the correct branch, regardless if empty or nonEmpty is first in the choice
branch.
But if your infoset does not contain a foo element, then Daffodil will
currently always pick the "empty" branch and unparse a 0. Instead, it should
unparse a 0 or 1 depending on whether or not empty or notEmpty is the first
choice branch.
> Unparser choice branch selection not conformant to DFDL standard
> ----------------------------------------------------------------
>
> Key: DAFFODIL-2324
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2324
> Project: Daffodil
> Issue Type: Bug
> Components: Back End
> Affects Versions: 2.5.0
> Reporter: Mike Beckerle
> Assignee: Mike McGann
> Priority: Major
>
> Erratum 5.60 of the DFDL spec clarifies how choice branch selection works.
> Our current schemas that use presence bits flags use a structure like this:
> {code:java}
> <choice>
> <sequence>
> <sequence dfdl:hiddenGroupRef="PI_true"/>
>
> <sequence>
> <element name="foo" minOccurs="0" ...../>
> <element name="bar" minOccurs="0" ..../>
> </sequence>
>
> <sequence dfdl:hiddenGroupRef="PI_false"/>
>
> </choice>{code}
> We depend on the fact that by default this chooses the PI_false hidden group
> when the incoming infoset event is not for a foo nor bar element.
> The DFDL spec says (with the Erratum/Clarification) that if we want PI_false
> to be chosen, then we must flip the order of these two choice branches.
> Daffodil is currently preferring the "more empty" of the two branches, and so
> seleting PI_false, rather than just taking the first possibly empty branch.
> Once we fix this behavior to conform to the spec., we will have to update
> DFDL schemas that use this behavior, and actually flip these branches.
> Based on that, we may want to put a compatibility flag into daffodil. Or
> perhaps a feature to generate a warning whenever there is more than one empty
> choice branch that *could* be selected, if the current functionality selects
> a default branch that is not the first possibly empty branch thena warning
> would be issued indicating that the branches should be reordered.
> The only schema I know of that is sensitive to this bug is mil-std-6017/VMF
> (and variants thereof).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
