[
https://issues.apache.org/jira/browse/DAFFODIL-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691285#comment-17691285
]
Mike McGann commented on DAFFODIL-2324:
---------------------------------------
I'm not able to reproduce this so I must have a misunderstanding somewhere. See
the following branch:
https://github.com/mike-mcgann/daffodil/tree/daffodil-2324-choice-branch
New tests are here:
https://github.com/mike-mcgann/daffodil/blob/daffodil-2324-choice-branch/daffodil-test/src/test/resources/org/apache/daffodil/section15/choice_groups/PresenceByChoice.tdml
I first reviewed the mil-std-2045 at hash 91bb7ac and saw that it had existing
tests for the presence bits. I added those here, as-is, named
presenceByChoice_1_1 and presenceByChoice_1_2. Those work as expected.
I then flipped around the choices and those tests are named
presenceByChoice_2_1 and presenceByChoice_2_2 and those work. These tests look
like it always consumes a bit on each branch so I don't think it fits the
description of this ticket where it says that both branches are empty.
I developed some new tests in schema presenceByChoice_empty. The emptyFirst
element has the following choice:
* empty, creates an empty hidden element; or
* an optional "foo" followed by a single character, and an optiinal "bar"
followed by a single character, and creates a notEmpty hidden element
Then there are two boolean elements to show if the first or second element was
selected, and a remainder element to hold extra text not processed at this
point.
When an empty document is passed in, both branches are eligible and the first
one is selected as shown in test presenceByChoice_emptyFirst. First choice is
true and second choice is false. If the input of "foo1bar2" is passed in, I
guess that both branches are still eligible? The text matches what the second
branch has, but the first branch has nothing to match on and so can match
against nothing. That is selected and no input is consumed. Then 'foo1bar' ends
up in the remainder element. Is that correct?
The presenceByChoice_emptySecond tests seem to work as I would expect.
> 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)
