[DFDL-WG] interesting bit-order variation

[Mike Beckerle]

So back when we were working on bit order, we decided that 3 of 4
combinations actually exist in the real world:

byte order bigEndian bit order mostSignificantBitFirst
byte order littleEndian bit order mostSignificantBitFirst
byte order littleEndian bit order leastSignificantBitFirst

I have, surprise surprise, run into a data format specification called
Asterix, which is public, and which uses the fourth combination.

This spec is all big-endian, except when they discuss the bits within a
byte they present them in order from most-significant bit first, to
least,...... but the labels they assign are least-significant first, so for
example they explain the bits of a byte starting by explaining bit 8, then
bit 7, etc. down to bit 1.

For example: (There's an image below. If you can't see it. it's from page
24 of the spec, URL for spec is below)

[image: Inline image 2]


Translating this into DFDL with mostSignificantBitFirst is possible. It's
just rather inconvenient. you have to take the data item size into account.
Some items are 16-bit words so the bits start from bit-16 first, some
things are 32-bits and start from bit 32, etc. etc. You have to subtract
from the word size to get the "mostSignificantBitFirst" bit position.

The spec is relatively modern in that it is byte/octet oriented. Uses
8-bits per character, and pays attention to not spanning byte boundaries
with fields except for 2's complement integers, of which a few are 14-bits,
i.e., not a multiple of 8-bits long.

It's a big spec, but the part I have reviewed is called "cat062" and it is
available here:

http://www.eurocontrol.int/sites/default/files/content/documents/nm/asterix/20141201-asterix-sdps-cat062-part9-v1.17.pdf

...mike

Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
www.tresys.com
Please note: Contributions to the DFDL Workgroup's email discussions are
subject to the OGF Intellectual Property Policy
<http://www.ogf.org/About/abt_policies.php>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20160309/5d7e10df/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot.png
Type: image/png
Size: 65467 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20160309/5d7e10df/attachment-0001.png>