If you look at the pcap schema. There's a need to have dfdl:byteOrder on a bunch of the elements and sequences up until it gets to the magic number element.

I am not thrilled about having to add these byteOrder properties to these elements and sequences.

Optimizing this requirement out requires that we recognize that no alignment other than to byte boundaries is needed, which means there is a known charset that has 8-bit mandatory alignment, or there are no delimiters, and there must be only alignment (in Bits) that is a multiple of 8 bits.

And if the component is an element of simple type, then it must not be binary numeric of more than one byte.

In that case, there's no way an alignment region can be needed other than one that skips forward to a byte boundary, so byte order isn't meaningful for the component.

But even that isn't enough. If an element is an array, and complex type, and the byte order varies inside child elements of the array, then the array could start with byte order say, bigEndian, same as what precedes the array contextually, but the last thing in it might be littleEndian, so when the next repetition is encountered, the current state is littleEndian, not bigEndian.

It's actually worse than that. The array element and its model-group might have no byteOrder needs, but a child inside it may need say, bigEndian. a later sibling of that needs littleEndian. In other words, we can't figure this out from looking at the starting context of the array.