[
https://issues.apache.org/jira/browse/DAFFODIL-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Beckerle resolved DAFFODIL-1630.
----------------------------------------
Resolution: Fixed
Fix Version/s: (was: deferred)
2.1.0
Fixed a long long time ago.
The class UnparseTargetLengthInBitsEv is one of the implementation classes for
this feature. This evaluates the length expression by way of the LengthEv, and
obviously is explicitly for unparsing case.
There needs to be a test that explicitly tests this, because there is an
erratum in the DFDL spec for it.
However, there's a separate JIRA ticket for another change in this area -
DAFFODIL-1584. So this one is being closed as fixed, and the other one will
create tests that cover this.
> lengthKind explicit and expressions when unparsing - expression not being
> evaluated but should be
> -------------------------------------------------------------------------------------------------
>
> Key: DAFFODIL-1630
> URL: https://issues.apache.org/jira/browse/DAFFODIL-1630
> Project: Daffodil
> Issue Type: Bug
> Components: Back End, DFDL Language
> Reporter: Michael Beckerle
> Assignee: Michael Beckerle
> Priority: Major
> Fix For: 2.1.0
>
>
> This was clarified on DFDL workgroup call on 2016-10-11
> Verify that Daffodil conforms to erratum 5.18 per below.
> lengthKind ' expression ' when unparsing
> Spec says "When dfdl:lengthKind is 'explicit' (and dfdl:length is an
> expression), 'delimited',
> 'prefixed', 'pattern' the data value is padded to the length given by the XSD
> minLength facet
> for type 'xs:string' or dfdl:textOutputMinLength property for other type" .
> This is not the latest agreed thinking. The desired behaviour is as
> documented by erratum 5.18
> in Experience Document 4, which states the expression is evaluated and the
> result taken as
> the explicit length. This has not yet been added to the spec.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
