[
https://issues.apache.org/jira/browse/DAFFODIL-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823656#comment-16823656
]
Michael Beckerle commented on DAFFODIL-2110:
--------------------------------------------
I think this ticket is mistaken. The test works properly.
We have numerous schemas that change bit order in the middle of a format. E.g.,
nato-stanag-5516 uses NACT envelopes which are big-endian and MSBF, but
little-endian LSBF payloads, for each message.
The test described can't be sensitive to bit order because there is nothing
smaller than a byte, nor that straddles byte boundaries, and in that situation,
bit order doesn't do anything.
Lastly, the scoping of properties in DFDL doesn't work the way you are
assuming. Having a byteOrder property on a sequence can only affect alignment
regions if the alignment isn't on a byte boundary. It otherwise has no affect,
and furthermore, does not affect the properties that apply to the contents of
the sequence.
For byteOrder to apply to both the sequence, and element 'C', the byteOrder
must be set in the lexically surrounding top-level format.
To be entirely clear, DFDL properties do not apply to the lexically nested
elements of a sequence or choice. They apply only to the construct itself upon
which they are written, not to enclosed children. The only way to get a
sweeping definition of a property over a sequence/choice AND its contents, is
at the lexically top-level annotation.
> Cannot change bitorder mid schema
> ---------------------------------
>
> Key: DAFFODIL-2110
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2110
> Project: Daffodil
> Issue Type: Bug
> Components: Back End
> Affects Versions: 2.4.0
> Reporter: Brandon Sloane
> Assignee: Brandon Sloane
> Priority: Major
> Attachments: BitOrder.tdml
>
>
> Setting the bitOrder in the middle of a schema appears to have no effect.
> Consider the following schema:
> {quote}<xs:element name="changeOnSequence" dfdl:lengthKind='implicit'>
> <xs:complexType>
> <xs:sequence>
> <xs:sequence dfdl:bitOrder="mostSignificantBitFirst">
> <xs:element name="A" type="xs:unsignedInt" dfdl:length="8"/>
> <xs:element name="B" type="xs:unsignedInt" dfdl:length="8"/>
> </xs:sequence>
> <xs:sequence dfdl:bitOrder="leastSignificantBitFirst"
> dfdl:byteOrder="littleEndian">
> <xs:element name="C" type="xs:unsignedInt" dfdl:length="8"
> dfdl:bitOrder="leastSignificantBitFirst" dfdl:byteOrder="littleEndian"/>
> <xs:element name="D" type="xs:unsignedInt" dfdl:length="8"/>
> </xs:sequence>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> {quote}
> With the following test:
> {quote}<tdml:parserTestCase name="bitOrderChangeOnSequence"
> root="changeOnSequence" model="s6" description="Tests changing bitOrder when
> on a byte boundary.">
> <document xmlns="http://www.ibm.com/xmlns/dfdl/testData";>
> <documentPart type="bits">
> 0000 0001
> 0000 0001
> 1000 0000
> 1000 0000
> </documentPart>
> </document>
> <tdml:infoset>
> <tdml:dfdlInfoset xmlns:xs="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns="http://example.com";>
> <changeOnSequence>
> <A>1</A>
> <B>1</B>
> <C>1</C>
> <D>1</D>
> </changeOnSequence>
> </tdml:dfdlInfoset>
> </tdml:infoset>
> </tdml:parserTestCase>
> {quote}
> (both snippets are in attached tdml as test name bitOrderChangeOnSequence.
> The attached TDML is an uncommited modified version of
> section05/simple_types/BitOrder.tdml )
> The actual result of parsing is:
> {quote}<changeOnSequence>
> <A>1</A>
> <B>1</B>
> <C>128</C>
> <D>128</D>
> </changeOnSequence>
> {quote}
> Note that the above schema attempts to change the bit order in 2 different
> ways:
> 1) On a sequence, and
> 2) On an element itself.
> Neither approach has any results.
> A possibly related issue is that ommiting the dfdl:byteOrder="littleEndian"
> on the xs:element results in an SDE, despite the fact that such is set on the
> enclosing sequence.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
