[So if you want BOM behavior it's because the beginning of a stream has special treatment, in this case it is reasonable to model the BOM as a separate element to be found at the beginning of a "stream", optionally hidden, perhaps optional, and compute dfdl:byteOrder in terms of its value. ] Works for me. The spec should deal with the (mostly) normal stuff expected. As a user I just want some way to use the DFDL processor to get the job done. I don't care if I have to clone the 'official' schema for a legacy file and tweak a few things; those are the hard cases. Sounds like there will be a way to deal with all the issues. The only thing I can think of, and it should be pretty rare, is when the length-prefix has a character count that doesn't include a BOM and there is a BOM present. Once the parser gets out of sync it may not be able to recover. Even so a log should show what element it was trying to parse and the position in the file for the start of the element. That would be enough to enable me to use a hex editor, figure out what the problem was and find a way around it.