Agile Delta Example EXI Program

["Adams, Joshua" <ja...@owlcyberdefense.com>]

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

Re: Agile Delta Example EXI Program

[Steve Lawrence <sl...@apache.org>]

+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 <ja...@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
>>
> 

Re: Agile Delta Example EXI Program

[Mike Beckerle <mb...@apache.org>]

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 <ja...@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
>