Added sample EXI program using Agile Delta #27
Conversation
jadams-tresys
left a comment
jadams-tresys
left a comment
There was a problem hiding this comment.
Please take a look at the inline comments for a couple issues that were noted during development that may require changes to Daffodil itself.
| //SchemaResolver resolver = new SchemaResolver() { | ||
| // public SchemaSource getSchema(String schemaID, String schemaPath, String namespaceURI) throws java.io.IOException { | ||
| // } | ||
| //}; | ||
| ////factory.setProperty(EFXProperty.SCHEMA_RESOLVER, resolver); | ||
| //factory.setSchema(schemaId); |
There was a problem hiding this comment.
This is where I ran into an issue with schema aware EXI. Agile Delta's SDK has an interface for a SchemaResolver which would be pretty straightforward to implement using the DFDLCatalogResolver under the hood. However, the DFDLCatalogResolver is not included in the Java API of Daffodil. I'm thinking that the right move is to expose the DFDLCatalogResolver in the Java API, but wanted to bring it up for discussion first.
This was also the case when using Exificient in the Daffodil Main.scala program, but since it is written in Scala it wasn't a big deal to just import it. The DFDLCatalogResolver can still be used in Java without adding it to the Java API, but using Scala objects in Java gets a bit ugly.
There was a problem hiding this comment.
We should expose the resolver in japi and sapi packages.
This really is just a pointer to the DFDLCatalogResolver which is already just using scala code but implementing a Java interface.
I.e., I would not bother with a per-method proxy/delegation.
| //}; | ||
| ////factory.setProperty(EFXProperty.SCHEMA_RESOLVER, resolver); | ||
| //factory.setSchema(schemaId); | ||
| factory.setProperty(EFXProperty.HEADER, true); |
There was a problem hiding this comment.
Doing some basic testing, it appears that Agile Delta and Exificient use different default values when encoding files. For example, compression is enabled by default in AD, but not in Exificient. Including this HEADER option adds a header to the EXI file specifying what options were used to encode it. This allows Exificient to handle AD's encoded files.
We will probably also want to enable this option in the Daffodil Main program as well when we use Exificient. In a quick test, enabling the HEADER option in this program only adds 1 byte to the outputted EXI file, which is definitely worth it to ensure compatibility between EXI implementations.
There was a problem hiding this comment.
Example should illustrate how to turn on this compression feature explicitly, not just add header so defaults are recorded.
Are there other interesting options as well.
mbeckerle
left a comment
mbeckerle
left a comment
There was a problem hiding this comment.
Needs to be showing use of the schema-aware API.
Add an XSLT in the middle so that it shows how EXI can avoid XML text but still allow transforms.
| //SchemaResolver resolver = new SchemaResolver() { | ||
| // public SchemaSource getSchema(String schemaID, String schemaPath, String namespaceURI) throws java.io.IOException { | ||
| // } | ||
| //}; | ||
| ////factory.setProperty(EFXProperty.SCHEMA_RESOLVER, resolver); | ||
| //factory.setSchema(schemaId); |
There was a problem hiding this comment.
We should expose the resolver in japi and sapi packages.
This really is just a pointer to the DFDLCatalogResolver which is already just using scala code but implementing a Java interface.
I.e., I would not bother with a per-method proxy/delegation.
| //}; | ||
| ////factory.setProperty(EFXProperty.SCHEMA_RESOLVER, resolver); | ||
| //factory.setSchema(schemaId); | ||
| factory.setProperty(EFXProperty.HEADER, true); |
There was a problem hiding this comment.
Example should illustrate how to turn on this compression feature explicitly, not just add header so defaults are recorded.
Are there other interesting options as well.
|
|
||
| The build.sbt file is a build script for the sbt - simple build tool. | ||
|
|
||
| You will need version 0.13.x or higher. |
There was a problem hiding this comment.
No point suggesting version 0.13.x unless you want to test that far back! Just say "Tested with sbt 1.6.1" (Which you could upgrade to 1.7.2)
|
|
||
| You will need version 0.13.x or higher. | ||
|
|
||
| You will also need Java 1.8 (aka Java 8) or higher JDK. |
There was a problem hiding this comment.
Say what you tested it with.
|
|
||
| You will need an internet connection to pull down the dependent libraries, including daffodil itself. | ||
|
|
||
| With those installed you can type 'sbt run' and it will download all dependencies as jar files, and then compile and run the HelloWorld.java program. |
There was a problem hiding this comment.
Update HelloEXI.java.
Also rephrase. Suggest part about using an AgileDelta eval/full library should go first. Given that, the rest will pull down automatically.
|
|
||
| is.close(); | ||
| os.close(); | ||
|
|
There was a problem hiding this comment.
I think the example should show how to transform the EXI data via XSLT to say Mars instead of World, so as to show how one can feed EXI data directly to XSLT without converting to XML text first.
|
Another thought. I think you should include some way to also demonstrate how the schema could be pre-compiled by the Agile Delta kit, and the compiled file used by the demo application. E.g., perhaps based on file extension it either compiles the schema on the fly or uses an already-compiled file. |
2 participants
Minimal Hello World style example using Agile Delta's EXI implementation.