[jira] [Updated] (DAFFODIL-1971) Statement order of evaluation not per DFDL Spec

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

     [ https://issues.apache.org/jira/browse/DAFFODIL-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Beckerle updated DAFFODIL-1971:
------------------------------------
    Priority: Critical  (was: Major)

> Statement order of evaluation not per DFDL Spec
> -----------------------------------------------
>
>                 Key: DAFFODIL-1971
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-1971
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Middle "End"
>    Affects Versions: 2.1.0
>            Reporter: Mike Beckerle
>            Priority: Critical
>
> Per the DFDL spec section 9.5, the order of evaluation of statements for model groups is not correct.
> This appears in the grammar
> {code}
>   final override lazy val termContentBody = prod("termContentBody") {
>     dfdlStatementEvaluations ~ groupLeftFraming ~ _content ~ groupRightFraming
>   }
> {code}
> This puts all the statement evaluations first. 
> However, asserts or discriminators with test expressions (not patterns) are executed AFTER the content of the group. So this needs to be split up so that the statements that are supposed to execute before appear before, and the ones that execute after are after.
> Note that per DFDL spec section 7.4.1, discriminators and asserts are mutually exclusive, and while there can be multiple asserts, there can be only one discriminator at a single annotation point.
> Note also DFDL spec section 9.5.2, which specifies that discriminators are evaluated even if the parsing of the content fails. This will also require special treatment in the model group combinators to be sure discriminators execute. The same problem does not occur for elements because the element combinators explicitly execute discriminators regardless of failure of the element, and after they are parsed. 
> test test_discrimExpression_04 behaves incorrectly because of this bug.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)