Mike, Thanks for the helpful and quick response. I was worried we might have to extract the fields with mathematical operations as you described.
Hopefully the DFDL Workgroup will add support for this type of packing so that LINK-16 schemas can be reused in SISO-J messages. When does the workgroup meet next? What do you think the likelihood is for a change like this to be accepted? Marshall Miller On Thu, Jan 11, 2018 at 3:48 PM, Mike Beckerle <[email protected]> wrote: > Marshall, > > > Looks like we'll have to give some thought to whether bigEndian and LSBF can > go together. We've had no actual examples of this until now. I will bring > that up with the OGF DFDL Workgroup. > > > But to deal with this today, these kinds of mixed bit order situations > generally require use of the dfdl:inputValueCalc and dfdl:outputValueCalc > properties. > > > A simple example is here: > > > https://github.com/rchampag/dfdl/blob/master/arinc429-label/localizer-deviation-label.dfdl.xsd > > > This was for individual bits, but in your case they would be wider integers. > > > For your 3 fields in the example I suggest you parse as 4 fields > > > h_slot2LSBs - 20 bits > > h_slot1 - 12 bits > > h_slot3 - 20 bits > > h_slot2MSBs - 12 bits > > > You would do this all bigEndian and mostSignificantBitFirst. > > > The above would go into a hidden group so they wouldn't show up in the > logical data. > > > Then you would have 3 logical ordinary, not hidden elements > > slot1 dfdl:inputValueCalc='{ ../h_slot1 }' > > slot2 dfdl:inputValueCalc='{ ( ../h_slot2MSBs * dfdl:int('x80000' ) + > ../h_slot2LSBs }' > > slot3 dfdl:inputValueCalc='{ ../h_slot3 }' > > > dfdl:int('x80000') constructs a integer from a hex string, and I think that's > the right value. Or maybe it's 'x100000'. > > > You can also use math.pow function as in > > > xs:int(math:pow(2, 19)) > > > (you need to add this namespace to your xs:schema element > xmlns:math='http://www.w3.org/2005/xpath-functions/math') > > > The tricky part is that for unparsing you must invert this using > dfdl:outputValueCalc. So the 4 hidden elements would be like this: > > > h_slot2LSBs dfdl:outputValueCalc="{ ../slot2 mod dfdl:int('x80000') }" > > h_slot1 dfdl:outputValueCalc='{ ../slot1 }' > > h_slot3 dfdl:outputValueCalc='{ ../slot3 }' > > h_slot2MSBs dfdl:outputValueCalc="{ ../slot2 idiv dfdl:int('x80000') }" > > > or something like that. My details here are probably off by 1 or something. > > > DFDL's Xpath-like expression language has the operators +, -, *, div, idiv, > mod, and the math.pow() function. Alas there's no shift nor a bit-wise & and > | operator. Generally it is possible to figure out how to achieve what you > want by way of mathematical operations. > > > Also note: If you want Link16 specific support we have a channel for FOUO > email support which is [email protected]. > > > ...mike beckerle > > Tresys > > > > ________________________________ > From: Marshall Miller <[email protected]> > Sent: Thursday, January 11, 2018 2:34:46 PM > To: [email protected] > Subject: Help implementing schema for SISO-J > > Hello, > > I am trying to implement a schema to describe a LINK-16 message > embedded within a DIS Signal PDU as described by SISO-STD-002 [1], > paragraph 5.2.2.9 and table 5.2.3; commonly referred to as SISO-J. > The problem is that fields are packed into 32 bit words with big > endian byte order, and little endian bitfield order. It is currently > an error to specify a byteOrder of bigEndian with a bitOrder of > leastSignificantBitFirst. Also, I have not found a way to set word > size; it appears that word size is implicitly set to the size of each > field. > > Following is a simple example to demonstrate how fields need to be > interpreted. It is just an example and does not represent any part of > a SISO-J message. > > Data is comprised of 3 unsigned integer bitfields: > slot1 is 12 bits > slot2 is 32 bits > slot3 is 20 bits > > Given an input with the following bytes in hex: > 01 23 45 67 89 AB CD EF > > Parsed results need to be (in hex): > slot1: 0567 > slot2: DEF01234 > slot3: 089ABC > > Explanation of results: > > Since the bitfields need to consume data in a leastSignificantBitFirst > order, it is easier to represent the input in right-to-left order > where bits are consumed starting at the right and moving toward the > left. Since words are 4 bytes, and in big endian order, the lowest > bit in the 4th byte is the first bit to be consumed. Reordering the > input data and consuming data from right to left yields the correct > field boundaries. > > 89 AB CD EF 01 23 45 67 parse fields right to left > 05 06 07 08 01 02 03 04 input byte position > > slot1 consumes the right 3 nibbles, slot2 consumes the next 8 nibbles, > and slot3 consumes the left 5 nibbles. > > Could you please let me know if there is a way to parse fields in this manner? > > > > Marshall Miller > > > [1] > https://www.sisostds.org/DesktopModules/Bring2mind/DMX/Download.aspx?Command=Core_Download&EntryId=43048&PortalId=0&TabId=105
