This was just a bug in Daffodil, which was actually fixed last week (DAFFODIL-2019). The fixed behavior is as you describe--the dfdl:byteOrder property should not have an affect on the resulting infoset value when parsing xs:hexBinary data.
- Steve On 12/17/18 11:23 AM, Costello, Roger L. wrote: > Hello DFDL community, > > My input file contains a single, 8-byte field: > > My DFDL schema specifies that the field consists of 8 xs:hexBinary bytes: > > <xs:elementname="Field" > type="xs:hexBinary" > dfdl:length="8" > dfdl:lengthKind="explicit" > > dfdl:lengthUnits="bytes"/> > > Through experimentation I have found that the value of the <Field> element > depends on the value of dfdl:byteOrder: If dfdl:byteOrder="littleEndian" then > the value of the <Field> element is 11 11 11 11 00 00 00 00. If > dfdl:byteOrder="bigEndian" then the value of the <Field> element is 00 00 00 > 00 > 11 11 11 11. > > Conversely, suppose my input file consists of this single, 8-byte field: > > My DFDL schema specifies that the field consists of 8 xs:string characters: > > <xs:elementname="Field" > type="xs:string" > dfdl:length="8" > dfdl:lengthKind="explicit" > > dfdl:lengthUnits="characters"/> > > Through experimentation I have found that the value of the <Field> element > does > _not_ depend on the value of dfdl:byteOrder. > > Why is that? > > It seems to me that in the first case (above) we have a sequence of bytes and > in > the second case we also have a sequence of bytes. The only difference being > that > in the first case the sequence is to be interpreted as a sequence of hex > digits > whereas in the second case the sequence is to be interpreted as a sequence of > characters. > > Why this difference in behavior between a sequence of hex digits versus a > sequence of characters? > > /Roger >
