Describes features of the data layering functionality not yet implemented, or not implemented as part of the initial release.


New annotations:

  • layerTransformArgs - A whitespace delimited list of string literals, or a DFDL expression returning a whitespace delimited string. The contents of this will be passed to the transform algorithm.

New transform algorithms:

  • midBitsToEnd - Paramaterized by 2 arguements provided through layerTransformArgs: x, y. Moves the y bits at bit indexes [x, x+y] to the end of the layer's content area, shifting subsequent bits y bits to the left to fill in the gap.
  • No labels

3 Comments

  1. Mike Beckerle

    See also page: 

    Proposal: Checksums, CRC, Parity - Layering Enhancements 


  2. Mike Beckerle

    If layering transformations can read and write DFDL variables, and dfdl:newVariableInstance is supported, the parameters can be provided by setting/binding a variable the purpose of which is to carry parameters to the layer transform. 

    This could be one DFDL variable per arg, or one variable for multiple args (which then would have to be pulled apart in some way by the layer transform code). 

    One could even "go meta" and have a DFDL variable defined only once at top level, but which provides the QNames of other DFDL variables the instances of which are set/bound and which carry the actual args. 

    There are implementation considerations to a layer transform reading variables at unparse time. The layer transform may have to suspend and resume, as do any computations referencing DFDL variables at unparse time. 

    However, assuming this use of variables works, I believe no specific mechanism other than this is needed to parameterize layer transforms. A polished dedicated property for this purpose could be added later if the variables mechanism is deemed too verbose. 

  3. Mike Beckerle

    Note: this midBitsToEnd feature turned out to not be needed. It was proposed to describe a specific data format situation where an outer data envelope format was bigEndian and mostSignificantBitFirst, but the payload was littleEndian and leastSignificantBitFirst, and the inner payload did not fill out all the bits of the final byte. From the perspective of the envelope format this makes the padding of the final byte appear to be in the middle of the data payload region, not at the end of it. 

    If the padding is viewed from the perspective of the payload, then it is at the end of the payload, and that is a cleaner way to describe the format. 

    Hence this midBitsToEnd mechanism is not required.