...
Code Block |
---|
dfdlx:layerTransform="someLayer" |
Then somewhere in Scala/Java code before compiling the schema one must call LayerCompilerRegistry.register(SomeLayerCompiler), and the SomeLayerCompiler object has to be defined on the classpath.
In the case of the tests in daffodil-test, the scala test driver code does this call.
This is sufficient for application developers using Daffodil via API from software.
However: It won't let a user run a new layer transform from the Daffodil CLI tool.
Enabling CLI Loading of Layers
To make the CLI work:
- The dfdlx:layerTransform property, if the name does not correspond to a registered LayerCompiler, it could dynamically load a class corresponding to it, using the service loader techniques already in use for UDFs and loadable validators.
That name must be the name associated with a class derived from LayerCompiler.
LayerCompilers are dynamically loaded service providers. See the META-INF/services/org.apache.daffodil.layers.LayerCompiler files in daffodil-runtime1-layers/src/main/resources, and daffodil-test/src/test/resourcesThis mechanism would also eliminate the need for API code to explicitly call the LayerCompilerRegistry.register(...) method. However, it is good practice to do that anyway, so as to get a Java linkage error (build/compile time of the software) rather than a dynamic runtime error.
The 'daffodil-runtime1-layers' Module
...
- aisPayloadArmoring
- IPv4Checksum - stripped down version of IPv4 checksums
- CheckDigits - check digit calculation in the style of the "OTH-Gold" data format.
Documentation
A web page on the Daffodil user site should contain links to doc about each layer transform that is part of the daffodil-layers jar.
Scaladoc(?) of each Layer Transform and of the Layering API.
There are two kinds:
- user documentation for a DFDL schema author on how to use one of the built-in layers.
- developer documentation for how to define a new layer transform for use in a data format DFDL schema.
User documentation should be via a web page on the Daffodil user site.
Developer documentation should be within the scaladoc of the Layering API classes.
- TBD: How to capture and exhibit this scaladoc for user-developers.
- These links should be to the scaladoc pages for each of these transforms.
- Each transform's scaladoc should be where the transforms are thoroughly documented.
- ??? There are pros/cons here.... needs discussion scaladoc is created in src/main/scala and it would end up almost repeating the example code which is in the src/test/resources and src/test/scala directories
Test Automation Plan
Testing of User-like Situations - Outside the Daffodil Repository Tree
...