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?
