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/... ...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>
