On 8/25/21 1:41 PM, Beckerle, Mike wrote: > 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.
Good point. Keep it easy at first make sense. It should be easy to add a feature to override the hardwired name if we realize it's needed.
