[
https://issues.apache.org/jira/browse/DAFFODIL-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149540#comment-17149540
]
Mike Beckerle edited comment on DAFFODIL-2361 at 7/1/20, 4:21 PM:
------------------------------------------------------------------
This bug is caused by the fact that for element item1, it has lengthKind
'explicit' and an expression. DFDL v1.0 defines that the expression IS
evaluated at unparse time in order to determine the length. For some types,
the string might be padded or truncated (type string only) based on whether
the logical value is too short or too long relative to the expression value.
The problem goes away if you use valueLength( implicitLenComplex/item1,
'bytes') because.... we're asking then for the valueLength of a simple element.
The valueLength of a simple element at unparse time does not need to evaluate
the expression because the valueLength excludes any padding (or the effect of
any truncation... hmm. not sure the DFDL spec clarifies the truncation aspect).
Hence, the value of the preceding length element can be determined, and then
when we eventually do unparse the item1, we're able to evaluate its length
expression.
But this begs the question of how DO we want to deal with a preceding length
field for a complex structure, where that preceding length field must be
calculated in terms of the length of the complex type element. I believe the
PCAP schema does this, and we can use that as an example. But it also may be
working around a real flaw here.
was (Author: mbeckerle):
This bug is caused by the fact that for element item1, it has lengthKind
'explicit' and an expression. DFDL v1.0 defines that the expression IS
evaluated at unparse time in order to determine the length. For some types
(strings really), the string might be padded or truncated based on whether the
logical value is too short or too long relative to the expression value.
The problem goes away if you use valueLength( implicitLenComplex/item1,
'bytes') because.... we're asking then for the valueLength of a simple element.
The valueLength of a simple element at unparse time does not need to evaluate
the expression because the valueLength excludes any padding (or the effect of
any truncation... hmm. not sure the DFDL spec clarifies the truncation aspect).
Hence, the value of the preceding length element can be determined, and then
when we eventually do unparse the item1, we're able to evaluate its length
expression.
But this begs the question of how DO we want to deal with a preceding length
field for a complex structure, where that preceding length field must be
calculated in terms of the length of the complex type element. I believe the
PCAP schema does this, and we can use that as an example. But it also may be
working around a real flaw here.
> valueLength not working as expected with complex elements, causing circular
> deadlocks during unparse
> ----------------------------------------------------------------------------------------------------
>
> Key: DAFFODIL-2361
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2361
> Project: Daffodil
> Issue Type: Bug
> Components: Unparsing
> Affects Versions: 2.6.0
> Reporter: Josh Adams
> Priority: Major
> Attachments: innerSeq.xsd, test.dat, test.info, test.xsd
>
>
> Ran into this issue while making changes to a production schema.
> Consider the following schema;
> <xs:element name="len" type="xs:unsignedInt" dfdl:outputValueCalc="\{
> dfdl:valueLength(../implicitLenComplex, 'bytes') }" />
> <xs:element name="implicitLenComplex">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="item1" type="xs:hexBinary" dfdl:length="\{ ../../len }"
> dfdl:lengthUnits="bytes" dfdl:lengthKind="explicit" />
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> I would reasonably expect that the outputValueCalc would work as expected and
> get the valueLength of the entire implicitLenComplex sequence, however this
> results in a circular deadlock.
>
> NOTE: if you change the outputValueCalc to
> dfdl:valueLength(../implicitLenComplex/item1, 'bytes') everything works as
> expected.
>
> I've attached a sample schema file and test data that demonstrates this issue.
>
> EDIT: I've added an additional schema that demonstrates that if the hexBinary
> element is wrapped inside an additional sequence and valueLength is called on
> the inner sequence it still results in the circular deadlock.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
