[
https://issues.apache.org/jira/browse/DAFFODIL-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698560#comment-17698560
]
Steve Lawrence commented on DAFFODIL-2801:
------------------------------------------
I've tracked down the difference between OCK parsed and implicit, though I'm
not yet sure where the bug is (or if maybe this is the correct behavior?):
In both cases, we successfully parse se1 and se2 and start to parse the arre1
element.
When occursCountKind="parsed", we successfully parse the 3.5 as ie2 and then
look for an infix separator. We find the separator, but then the choice fails
to parse the "a" as expected. The result is "MissingItem", which causes
parseOneInstanceWithMaybePoU to backtrack to before the separator and return
Done for the array. Since the array is done, and the bitPosition was reset to
before the "/a", we can then parse the prefix separator, the se5 element, and
so on.
When occursCountKind="implicit", as before we successfully parse the 3.5 as ie2
and then look for an infix separator. And like before, we find the separator
and the choice fails to parse the following "a". This is where things differ
from parsed. Instead of returning "MissingItem" with the parse failure, we
instead return "AbsenRep" (we failed to parse the choice, that failure was zero
length, which I guess means AbsentRep when OKC is implicit?). Because we return
Absent, parseOneInstanceWithMaybePoU sets the bitPosition to *after* the infix
separator, I guess implying that we successfully parsed the infix separator,
and "successfully" parsed a zero length model group after that. We don't say
that the array is done, so we try to parse another array element, but we expect
another infix separator for the next array element and only see the "a" and so
the array element fails. The arry is now done and so we we try to parse se5 and
its prefix separator, but because the bitPosition is at the "a", it doesn't
find that and things fail for good.
So it seems like things go off the rails because AbsentRep is returned and that
sets the bitPosition to after the infix separator so we can't tell it's
actually a prefix separator for following elements. Looking at the code, this
all seems very intentional and has code coverage.
Ultimately, it seems like OCK parsed is nonPositional and so returns
MissingItem on zero length, but OCK implicit is positional and so returns
AbsentRep on zero length (since the array element is optional), and there is a
comment explaining why this makes sense:
https://github.com/apache/daffodil/blob/main/daffodil-runtime1/src/main/scala/org/apache/daffodil/runtime1/processors/parsers/SeparatedSequenceChildParseResultHelper.scala#L134-L150
Maybe there are some cases like this where is doesn't make sense, still TBD,
but I wanted to get my findings written down.
> Array with Choice parses incorrectly when occursCountKind is implicit
> ---------------------------------------------------------------------
>
> Key: DAFFODIL-2801
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2801
> Project: Daffodil
> Issue Type: Bug
> Components: Back End
> Affects Versions: 3.4.0
> Reporter: Olabusayo Kilo
> Assignee: Steve Lawrence
> Priority: Major
> Fix For: 3.5.0
>
> Attachments: TestImplicitvParsed.scala, implicitvparsed.tdml
>
>
> When an inner array with an infix separator (contained in a sequence with a
> prefix separator) has a choice within it and is occurs count kind implicit,
> it's unable to correctly backtrack and find the separator and fails with a
> separator not found. The exact same scenario with the OCK set to parsed,
> works as expected. Attached are the tdml files.
> Tested with 3.4.0 and 3.5.0 snapshot.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
