Michael Beckerle created DAFFODIL-1880:
------------------------------------------
Summary: MandatoryTextAlignment won't fill out prior byte if it
has different bit order
Key: DAFFODIL-1880
URL: https://issues.apache.org/jira/browse/DAFFODIL-1880
Project: Daffodil
Issue Type: Bug
Components: Back End
Affects Versions: 2.0.0
Reporter: Michael Beckerle
Fix For: deferred
Assume you are unparsing.
If you are positioned on bit 3 of a byte, in bitOrder leastSignificantBitFirst,
and what follows that is text in say, US-ASCII, which has mandatory byte
alignment, you would expect that the remaining 5 bits would get filled in
automatically, and then the unparsing of the US-ASCII text would begin on a
byte boundary.
However, note that the 5 bits of the byte that must be filled, must be filled
based on LSBF bit order, which is *not* the bit order specified for the
US-ASCII encoding.
Two issues:
1) When filling these 5 bits, the bit order to be used is the bit order that
was in effect for that byte, which is BEFORE the text string. Daffodil is
currently trying to fill this in using the bit order specified for the text,
and that's MSBF, so we get an error because we're changing bit order not on a
byte boundary.
Tests like test_mixedEncoding2 only work because dummy empty xs:sequences with
alignment of 8 bits are inserted so that the LSBF data ends on a byte boundary
before the text is considered. This makes the bitOrder change occur on a byte
boundary.
2) why does US-ASCII have *any* bit order specified? It's only relevant to have
bitOrder for encodings that involve partial bytes. Really we need bitOrder of
LSBF, MSBF, or "none" for byte-oriented encodings.
3) in general, whenever we are filling alignmentFill regions, any fragment
bytes are filled based on the existing current bit order that was used to start
them.
To see this issue, find the test test_mixedEncoding2 and modify the "e2"
element schema, removing the <xs:sequence dfdl:alignment="8"/>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
