...

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

...