+1
Anyone using Daffodil and schemas/jars that work with Daffodil will
likely need to use our special entity resolver logic for things just
like in this case. Making that public and Java friendly is reasonable.
Though that does mean we need to think abit more carefully about future
changes and backwards compatibility. Though that's probably not a big
concern at this point--this resolver logic feels pretty stable.
As to naming, another approch might be to just call it something like
"DaffodilEntityResolver", making it clear that if you need an entity
resolver that uses the same logic as Daffodil schema compilation then
this is what you want. The fact that Daffodil has special logic for
searching on classpaths or XML catalogs maybe isn't as important? I
don't feel strongly about the name though.
On 9/29/22 11:12 AM, Mike Beckerle wrote:
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
