Uploaded image for project: 'Daffodil'
  1. Daffodil
  2. DAFFODIL-2689

Asterix format uses DFDL disallowed 4th combination of byte order and bit order

Attach filesAttach ScreenshotAdd voteVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • New Feature
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 3.3.0
    • None
    • Back End, Front End


      The Asterix CAT 034 message uses byteOrder bigEndian but bit order leastSignificantBitFirst for numbers that span bytes. For example they describe an 11-bit integer in this way:

      In this picture you can see they are numbering the bits from the right, leastSignificantBitFirst starting from 1. But the COUNTER field spans all of Octet 3, but also includes the least significant 3 bits of Octet 2. In those least significant 3 bits are the most significant (numerically) 3 bits of the 11 bit COUNTER integer, so this is bigEndian byte order, but leastSignificantBitFirst bit order.

      The DFDL standard does not allow this combination of bitOrder and byteOrder, as there was no known documented use case at the time the new bitOrder property was added to the DFDL specification. It was however, proposed that it was likely this combination would be needed, and here is a well-documented use case. 

      So Daffodil should lift this restriction and allow this combination.

      The workaround in the mean time is to parse this counter as two separate integers, one 3 bits and one 8 bits, and use an inputValueCalc expression to compute a field with the expected value. 



          This comment will be Viewable by All Users Viewable by All Users


            Unassigned Unassigned
            mbeckerle Mike Beckerle




                Issue deployment