Need clarity: when unparsing dfdl:length expression is evaluated or not?
I know we discussed this extensively, and there are notes that the IBM DFDL implementation evaluates a dfdl:length expression when unparsing. But searching the mail history, the trackers, etc. I cannot find a clear definitive statement of what we finally decided as to whether this is the official behavior or not. I cannot find language in the DFDL spec that says that the dfdl:length expression is or is not evaluated. (No such problem for dfdl:occursCountKind 'expression'. There we are very clear it is NOT evaluated when unparsing.) There is this statement in the discussion of dfdl:contentLength function: "When unparsing with dfdl:lengthKind "explicit", the calculation of dfdl:contentLength() returns the value of the dfdl:length property." It does not say whether this forces the expression (if dfdl:length is an expression) to be evaluated or not, though it implies it must be evaluated because otherwise it would be undefined in that situation. Is this the only situation during unparsing when the dfdl:length expression is evaluated? ...mike Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>
Digging through the minutes of calls this year I found this statement in https://redmine.ogf.org/issues/258 which is the resolution of action 276. "WG agreed to reverse erratum 2.100. The original variable length behaviour scenario that motivated 2.100 in the first place can still be achieved using outputValueCalc with dfdl:valueLength(). Spec will revert to describing lengthKind 'explicit' as fixed length for both literal and expression lengths." I think this means dfdl:length expressions are evaluated to get the length even when unparsing. We need to flat out say that someplace. It's way too hard to find this statement. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php> On Thu, May 7, 2015 at 10:12 AM, Mike Beckerle <mbeckerle.dfdl@gmail.com> wrote:
I know we discussed this extensively, and there are notes that the IBM DFDL implementation evaluates a dfdl:length expression when unparsing.
But searching the mail history, the trackers, etc. I cannot find a clear definitive statement of what we finally decided as to whether this is the official behavior or not.
I cannot find language in the DFDL spec that says that the dfdl:length expression is or is not evaluated. (No such problem for dfdl:occursCountKind 'expression'. There we are very clear it is NOT evaluated when unparsing.)
There is this statement in the discussion of dfdl:contentLength function:
"When unparsing with dfdl:lengthKind "explicit", the calculation of dfdl:contentLength() returns the value of the dfdl:length property."
It does not say whether this forces the expression (if dfdl:length is an expression) to be evaluated or not, though it implies it must be evaluated because otherwise it would be undefined in that situation.
Is this the only situation during unparsing when the dfdl:length expression is evaluated?
...mike
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>
Ok, I found erratum 5.18 which is clear about this. I had to download the latest version. This matter is closed. Yes the dfdl:length expression IS evaluated for dfdl:lengthKind 'explicit'. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php> On Thu, May 7, 2015 at 10:27 AM, Mike Beckerle <mbeckerle.dfdl@gmail.com> wrote:
Digging through the minutes of calls this year I found this statement in https://redmine.ogf.org/issues/258 which is the resolution of action 276.
"WG agreed to reverse erratum 2.100. The original variable length behaviour scenario that motivated 2.100 in the first place can still be achieved using outputValueCalc with dfdl:valueLength(). Spec will revert to describing lengthKind 'explicit' as fixed length for both literal and expression lengths."
I think this means dfdl:length expressions are evaluated to get the length even when unparsing.
We need to flat out say that someplace. It's way too hard to find this statement.
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>
On Thu, May 7, 2015 at 10:12 AM, Mike Beckerle <mbeckerle.dfdl@gmail.com> wrote:
I know we discussed this extensively, and there are notes that the IBM DFDL implementation evaluates a dfdl:length expression when unparsing.
But searching the mail history, the trackers, etc. I cannot find a clear definitive statement of what we finally decided as to whether this is the official behavior or not.
I cannot find language in the DFDL spec that says that the dfdl:length expression is or is not evaluated. (No such problem for dfdl:occursCountKind 'expression'. There we are very clear it is NOT evaluated when unparsing.)
There is this statement in the discussion of dfdl:contentLength function:
"When unparsing with dfdl:lengthKind "explicit", the calculation of dfdl:contentLength() returns the value of the dfdl:length property."
It does not say whether this forces the expression (if dfdl:length is an expression) to be evaluated or not, though it implies it must be evaluated because otherwise it would be undefined in that situation.
Is this the only situation during unparsing when the dfdl:length expression is evaluated?
...mike
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>
participants (1)
-
Mike Beckerle