I think exposing the DFDLCatalogResolver to the Java API makes perfect sense.
I wonder if this class should be renamed to DFDLClasspathResolver, since the key thing it does that is different from a standard resolver is to search the classpath for the schemaLocation entries. On Wed, Sep 28, 2022 at 10:21 AM Adams, Joshua <jad...@owlcyberdefense.com> wrote: > Hello all, > > I've implemented a basic "Hello World" style example program using Agile > Delta's EXI implementaion with Daffodil: > > https://github.com/OpenDFDL/examples/pull/27 > > There is one issue in particular that I wanted to bring up. Right now it > cannot do schema aware EXI as it can't always resolve schemas correctly by > default. The Agile Delta SDK does have a SchemaResolver interface that > would be pretty straightforward to impelment using Daffodil's > DFDLCatalogResolver. However, the DFDLCatalogResolver is not exposed to > the Java API (which is what this example is using). It seems to me that > the right thing to do would be to expose the DFDLCatalogResolver to the > Java API but figured it should be brought up for general discussion. > > DFDLCatalogResolver is implementing a Java interface under the hood > (org.xml.sax.EntityResolver) and we expose most of the other SAX interfaces > that Daffodil implements anyways. DFDLCatalogResolver was also needed when > implementing the Exificient support in the Daffodil Main program, but since > that is written in Scala and is part of Daffodil itself, it wasn't a big > deal to just import the DFDLCatalogResolver class. > > Please let me know what you think the correct path forward is. I'll take > feedback either in this thread or in the pull request linked above. > > Josh Adams >
