We need to flat out say that someplace. It's way too hard to find this statement.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.I think this means dfdl:length expressions are evaluated to get the length even when unparsing.
"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."Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property PolicyOn Thu, May 7, 2015 at 10:12 AM, Mike Beckerle <mbeckerle.dfdl@gmail.com> wrote:...mikeIs this the only situation during unparsing when the dfdl:length expression is evaluated?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.There is this statement in the discussion of dfdl:contentLength function:I know we discussed this extensively, and there are notes that the IBM DFDL implementation evaluates a dfdl:length expression when unparsing.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.)
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.
"When unparsing with dfdl:lengthKind "explicit", the calculation of dfdl:contentLength() returns the value of the dfdl:length property."Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy