Mike Beckerle created DAFFODIL-2437:
---------------------------------------
Summary: dfdlx:direction property for defineVariable
Key: DAFFODIL-2437
URL: https://issues.apache.org/jira/browse/DAFFODIL-2437
Project: Daffodil
Issue Type: New Feature
Components: Back End, Front End
Affects Versions: 3.0.0
Reporter: Mike Beckerle
Fix For: 3.1.0
DFDL is missing a property on dfdl:newVariableInstance and dfdl:setVariable (or
perhaps it should be on the dfdl:defineVariable) to indicate if they are to be
evaluated at parse, unparse, or both.
I have updated the PCAP schema on github to illustrate this issue.
This is a pull request (code review) of the changes
[https://github.com/DFDLSchemas/PCAP/pull/10]
In the PCAP schema the IPSrcGrp group ref appears immediately before the IPSrc
element. Similarly the IPDestGrp reference appears immediately before the
IPDest element.
These groups contain elements which are the individual binary bytes of the IP
Source and IP Dest addresses. They are 4 unsigned bytes.
When parsing these are parsed and then their values concatenated as strings
into a string like "1.2.3.4".
When unparsing, these groups use dfdl:outputValueCalc to take apart a string
like "1.2.3.4" (which appears in the infoset), back into its individual digits
1, 2, 3, 4, and creates an unsignedByte value of each number.
The problem is, these groups are absolute nonsense if you view the
dfdl:newVariableInstance defaultValue expression as being evaluated at parse
time. The expression is for use *only* at unparse time and immediately does a
forward reference to the following IPSrc member containing the "1.2.3.4" type
string.
Without some sort of additional property on dfdl:newVariableInstance and
dfdl:setVariable (or dfdl:defineVariable) to indicate that this only should be
evaluated at unparse time, there is no way to suppress evaluation and perform
it only at unparse time.
I suggest we need an additional property on newVariableInstance and setVariable
(or on dfdl:defineVariable) which I suggest is called 'direction', with values
'parse', 'unparse', 'both'. This property defaults to 'both', but if set to
'unparse' only evaluates the expression (and binds/sets variable) during that
direction of processing.
This property setting also loosens the DFDL spec restriction that setVariable
and newVariableInstance expressions only refer backward. That restriction makes
variables fairly useless when unparsing, as most usage of variables from
dfdl:outputValueCalc would be to capture common subexpressions that are doing
forward reference.
(Note: maybe the values of the property should be "input", "output" and "both"
to correspond to dfdl:inputValueCalc and dfdl:outputValueCalc property names?)
Standard practice now is such new DFDL features must be created as experimental
features in an implementation and then proposed for inclusion in the DFDL
language.
An experimental feature writeup of this proposal is needed to describe the
implementation once we have experience with it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
