[jira] [Assigned] (DAFFODIL-897) TDML runner must support bitOrder variations

["Michael Beckerle (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Beckerle reassigned DAFFODIL-897:
-----------------------------------------

    Assignee: Michael Beckerle

> 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)