The trace output can be improved a little, and then a lot.
A little: just remove the printing out of the parser - not relevant to a DFDL user.
A lot: Examples below of
- better data dump format, with text + hex, or just text, or just hex
- remove all the redundant parts of filenames. Use just the filename (so long as it is unambiguous), and then at the end of the trace display which files are located in what directories.
- short schema component designators (see https://opensource.ncsa.illinois.edu/confluence/pages/viewpage.action?pageId=22053271)
- optional use of the Unicode illustration characters: like ␍␊ which is way better than actually doing a CR and LF because those move the text around. (There are these Unicode characters for all the otherwise non-printing control characters. They are #x240A for linefeed and #x240D for carriage return. You can guess the others.) Note however, that on MS-Windows, the ordinary cmd console isn't unicode-capable by default, so we need these to print as something else on that platform.
My experience is that
(1) you sometimes need to see what came right before stopping point so as to infer the cause, not just look at the consequences, hence, the dump starts a little before where the actual stop was.
(2) unless the data is all text in a uniform encoding with no decoding errors, you will need to see hex and text or both to figure out what could be going on.
So I'm just laying out for you what that might look like to solicit feedback. Currently the stuff we print has had very little thought put into how it is displayed.
So, in a scenario where there is a possible mixture of binary data and text data, your message might be:
If you were in a 100% text and uniform encoding scenario, then perhaps the dump would drop the hex and make the text lines longer: