[
https://issues.apache.org/jira/browse/DAFFODIL-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16313689#comment-16313689
]
Michael Beckerle edited comment on DAFFODIL-897 at 1/5/18 7:23 PM:
-------------------------------------------------------------------
This bug is about the TDML runner not checking for it's own requirements on how
tdml:documents are expressed.
Eg., when bitOrder changes across the tdml:documentPart parts, then the
tdml:document must also specify a bitOrder. But this isn't being checked.
These tests fail because the TDML runner isn't insuring this is the case and
issuing a diagnostic message.
was (Author: mbeckerle):
Very stale bug. TDML runner has had full support for LSBF bit order and quite
extensive test coverage of this for some time now.
> TDML runner must support bitOrder variations
> --------------------------------------------
>
> Key: DAFFODIL-897
> URL: https://issues.apache.org/jira/browse/DAFFODIL-897
> Project: Daffodil
> Issue Type: Improvement
> Components: Infrastructure, QA, TDML Runner
> Affects Versions: s11
> Reporter: Michael Beckerle
> Assignee: Michael Beckerle
> Fix For: deferred
>
>
> 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
(v6.4.14#64029)
