One further comment at the end.
________________________________
From: Steve Lawrence <slawre...@apache.org>
Sent: Monday, August 23, 2021 2:23 PM
To: dev@daffodil.apache.org <dev@daffodil.apache.org>
Subject: Re: Please review mock up idea for checksum calculations in DFDL
On 8/23/21 1:51 PM, Beckerle, Mike wrote:
> Comments below see @@@mb
>
> ________________________________
> From: Steve Lawrence <slawre...@apache.org>
> Sent: Monday, August 9, 2021 12:18 PM
> To: dev@daffodil.apache.org <dev@daffodil.apache.org>
> Subject: Re: Please review mock up idea for checksum calculations in DFDL
>
> Some comments:
>
> 1) I like the idea that the layers write to a variable, but it seems
> like the variables are hard coded in the layer transformer? What are
> your thoughts on having the variable defined in a property so that the
> user has more control over the naming/definition of it, maybe via
> something like dfdlx:runtimeProperties? For example:
>
> <xs:sequence dfdlx:layerTransform="checksum"
> dfdlx:runtimeProperties="resultVariable=checksumPart1">...
>
> @@@ given that a layer transform can be defined with a unique namespace
> defined by way of a URI, there's never a need to be
> concerned about naming conflicts. So I think ability to choose the variables
> names and provide them is overkill.
This is maybe a bit contrived, but one benefit of some configurability
is that if you have a format with two of the same checksums for
different parts of the data, you don't need newVariableInstance stuff.
For example:
<dfdl:defineVariable name="checksumHeader" ... />
<dfdl:defineVariable name="checksumPayload" ... />
<xs:sequence>
<xs:sequence xmlns:chksum="urn:checksum"
dfdl:layerParameters="res=checksumHeader">
<xs:element ref="Header" />
</xs:sequence>
<xs:sequence xmlns:chksum="urn:checksum"
dfdl:layerParameters="res=checksumPayload">
<xs:element ref="Payload" />
</xs:sequence>
</xs:sequence>
So it's just a bit cleaner looking. Though, I'm not sure that's a strong
argument for configuring the variables. I imagine in most formats where
there's multiple of the same checksums then it's in an array and you'd
need new variable instance since the number of checksums isn't known.
I think this is a "let's see" kind of issue. We can use hardwired variables for
now, and add a feature later to pass in QNames of variables for the layer to
use if we find it too clumsy.
...
