Mike

We have reviewed the document.

So MIL-STD-2045 does not in fact reverse the physical bit order on the wire. As you point out in your comment, you don't know of a format that does. Therefore we do not need three enums for dfdl:bitOrder for DFDL 1.0.  We should just add the enums that we need, like we propose for dfdl:byteOrder.

However we are still having trouble relating your description of Number Model to the example quoted from MIL-STD-2045. Let me give an example of what we understand the MIL-STD-2045 example to be implying, and you can say whether we have the correct understanding. Assume big-endian byte order and twos complement binary for integers. You'll need to look at this in rich text to see the colours.

Logical data:
Struct length=16 bits
        FieldA  type=int, length=3 bits, value=3
        FieldB  type=int, length=7 bits, value=9
        FieldC  type=int, length=4 bits, value=5
        FieldD  type=int, length=2 bits, value=2

MSBF (how current DFDL parser would expect bits):
      01100010 01010110
      AAABBBBB BBCCCCDD
      M      L M      L    

LSBF (how MIL-STD-2045 would expect bits):
        01001011 10010100
        BBBBBAAA DDCCCCBB
      M      L M      L    

If that is correct, then we find this a good way to illustrate the concept.

How analogous is this bit ordering stuff to bi-directional text? I ask because we have properties textBidiOrder 'implicit' & 'visual', and textBidiOrientation 'LTR' & 'RTL'. If there is a good analogy then we could use the same terminology. If it is not then we should not. Though it should be pointed out that we have deferred action 241 so this area is not fully understood.

Regards

Steve Hanson
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848



From:        Mike Beckerle <mbeckerle.dfdl@gmail.com>
To:        "dfdl-wg@ogf.org" <dfdl-wg@ogf.org>,
Date:        17/07/2014 23:29
Subject:        [DFDL-WG] Please review - New version of bit order/MIL-STD-2045        document
Sent by:        dfdl-wg-bounces@ogf.org

---

I posted this to our documents.  http://redmine.ogf.org/dmsf_files/13300

This version is quite different. This version proposes that there are actually two different variations on the least-significant-bit first format.

One is where the bits are actually reversed (logical 0xE2 becomes 0x47 when unparsed to a file)

The other is where the bits are simply interpreted as LSB first, but the bytes are stored 'normally'. (0xE2 is in the file, but the 'first' 3 bits of it are 010, not 111.)

Turns out it is this latter form that MIL-STD-2045 and related standards need, and that the Daffodil code implements today.

I hope this version clarifies some things. You'll see there is a need to come up with useful names for these concepts when you read the document.

...mikeb

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
--
 dfdl-wg mailing list
 dfdl-wg@ogf.org
 https://www.ogf.org/mailman/listinfo/dfdl-wg

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU