The -I sax option wasn't a mistake. It was added for the SAX parse/unparsed update Lola worked back in 2020 and 2021.
Dave -----Original Message----- From: Adams, Joshua <jad...@owlcyberdefense.com> Sent: Monday, July 11, 2022 3:26 PM To: dev@daffodil.apache.org; mbecke...@apache.org Subject: Re: CLI -I sax feature - remove? Funnily enough I was just having a conversation with Dave Thompson about this very thing. When I mentioned that we will have a "-I exi" option for the command line tool, which from Daffodil's perspective will be just like using SAX, he asked if he will need to specify the "-I sax" option, or if that option will just go away. I am in full agreement of removing the "-I sax" option as, like you said, SAX usage is inherently an API and I can't think of an easy way to pass a SAX ContentHandler over the command line. Adding an EXI option to the Daffodil CLI tool can kill 2 birds with one stone in that we will be adding support for EXI as well as demonstrating how to pass in your own SAX ContentHandler. Josh ________________________________ From: Mike Beckerle <mbecke...@apache.org> Sent: Monday, July 11, 2022 3:19 PM To: dev@daffodil.apache.org <dev@daffodil.apache.org> Subject: CLI -I sax feature - remove? In the CLI, there is the -I option to specify infoset-type. One of the choices is 'sax'. This is a mistake I think. This is really "XML text by way of calling the SAX API". It's effectively a testing mode for us. SAX usage is inherently an API. I believe we should remove this feature from the CLI, because it creates a lot of confusion. It requires test-mode things to be in the main-libraries where the CLI can find them. If we require SAX to be used as it is intended, from applications calling Daffodil via APIs, then all this "xml text to/from SAX-event" code all ends up in src/test where it belongs. Thoughts?
