[
https://issues.apache.org/jira/browse/DAFFODIL-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230820#comment-17230820
]
Steve Lawrence commented on DAFFODIL-2437:
------------------------------------------
Is this a duplicate of DFDL-2429?
> 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
> Priority: Major
> 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)
