[
https://issues.apache.org/jira/browse/DAFFODIL-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Beckerle resolved DAFFODIL-897.
---------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
This ticket slipped through the cracks. It was implemented years ago and has
been a feature of the TDML runner since work on the mil-std-2045 DFDL schema
was done back in 2013.
Example of this is test_MIL2045_47001D_1
> TDML runner must check tdml:document bitOrder usage in test cases
> -----------------------------------------------------------------
>
> Key: DAFFODIL-897
> URL: https://issues.apache.org/jira/browse/DAFFODIL-897
> Project: Daffodil
> Issue Type: Bug
> Components: Infrastructure, QA, TDML Runner
> Affects Versions: s11
> Reporter: Michael Beckerle
> Priority: Major
> Fix For: 2.0.0
>
>
> See DFDL-896 for bitOrder feature.
> In order to test this feature, the ability to specify data in binary, but
> with least-significant bit first is needed. Otherwise we'll be unable to
> create sufficient test cases.
> There are two possible ways this can work.
> Consider a single byte with 3 bit fields within it, a 3-bit-long field
> containing value 3, or binary 011, another 3-bit-long field containing value
> 4 or binary 100, and a 2-bit-long field containing value 1 or binary 01.
> The TDML of Daffodil today only supports most-significant-bit-first bit order
> so:
> <documentPart type="bits"> 011 100 01</documentPart>
> That is equivalent to the byte 0x71 hex.
> For least-significant-bit-first, there are a few possibilities.
> One possibility is to add a bitOrder="MSBFirst/LSBFirst" attribute to
> documentPart. The default would be MSBFirst, which is consistent with today's
> behavior. The new value of LSBFirst would mean that we process the bits line
> by line, and concatenate them in LSB First order, though each line is written
> MSB-first order (the normal way we write numbers, i.e., where 011 binary
> means 3. This is consistent with some dump tools we have seen. So the same 3
> fields of data would be:
> <documentPart type="bits" bitOrder="LSBitFirst">
> xxxxx011 first field
> xx100xxx second field
> 01xxxxxx third field.
> </documentPart>
> Notice that the 'x' characters are ignored. So this is equivalent to writing
> <documentPart type="bits" bitOrder="LSBitFirst">
> 01 100 011 first second and third
> </documentPart>
> But see how the bits on the line are interpreted as numbered from right to
> left. Hence, viewed as a numeric byte in the data, this would be hex C6.
> The bitOrder attribute should be usable with any documentPart type, not just
> bits. So equivalent to the above:
> <documentPart type="byte" bitOrder="LSBitFirst">
> C6 first second and third
> </documentPart>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
