Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
2.0.0
-
None
-
None
Description
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"/>