SAX and EXI are related by SAX being the efficient way to talk to an EXI library "without having to know anything about EXI".
SAX is the common API that multiple EXI libraries will all support, so enables daffodil to support multiple EXI libraries without embedding one in our code base. (StAX *might* also be supported, unclear. SAX is far more common.) Since at least one of the important EXI implementations is closed source, this lack of being tied to any EXI implementation is important for our users I think. RE taking features out of the CLI. I'm not opposed to having sensible testing capabilities in the CLI. Maybe we just need to document them separately. But it does drag many things into our dependencies that wouldn't otherwise be there. Though only for the daffodil-cli module, so maybe that's ok. I think tying our CLI to one specific EXI implementation with a compatible open-source license is "acceptable", but not preferred. I'd rather it accommodated the selection of an EXI implementation by some dynamic means using standard APIs like SAX. I think it has become clear that we need to have an EXI features discussion and capture the goals and requirements. I will start a separate thread on this. On Mon, Jul 18, 2022 at 9:49 AM Steve Lawrence <slawre...@apache.org> wrote: > I would argue having a -I exi capability is useful, the output would > just be a EXI blob of data rather than XML text. This could then be fed > into things that understand the EXI data format. > > It's also not clear to me how EXI and SAX are related. For the new EXI > infoset outputter, I assume we would directly use the EXI library API to > create an EXI blob? > > > On 7/11/22 3:25 PM, Adams, Joshua wrote: > > 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? > > > >
