[
https://issues.apache.org/jira/browse/DAFFODIL-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415500#comment-17415500
]
Mike Beckerle commented on DAFFODIL-2559:
-----------------------------------------
This feature may not be needed. There are only a few cases in the format where
this is needed.
An alternative way to capture this format is roughly like this:
{code:xml}
<choice>
<sequence>
<element name="i" type="xs:int"/>
... any amount of stuff here ...
<element name "flag" type="xs:string" dfdl:length="1"/>
<annotation><appinfo ...>
<dfdl:discriminator>{ flag eq 'i' }</dfdl:discriminator>
</appinfo></annotation>
</sequence>
<sequence>
<element name="f" type="xs:float"/>
... any amount of stuff here ...
<element name "flag" type="xs:string" dfdl:length="1"/>
<annotation><appinfo ...>
<dfdl:discriminator>{ flag eq 'f' }</dfdl:discriminator>
</appinfo></annotation>
</sequence>
</choice>{code}
The above has the disadvantage of backtracking, rather than peeking ahead at
the flag first to discriminate the choice.
In the absence of many more use cases for this feature; however, this may be
adequate.
Note that the redundancy of the above code can be factored out to avoid as a
named group to avoid the need to express anything more than once like this:
{code:xml}
<annotation><appinfo .... >
<dfdl:defineVariable name="flagVar" type="xs:string"/>
</appinfo></annotation>
<group name="flagGroup">
<sequence>
... any amount of stuff here ...
<element name "flag" type="xs:string" dfdl:length="1"/>
<annotation><appinfo ...>
<dfdl:discriminator>{ flag eq $tns:flagVar }</dfdl:discriminator>
</appinfo></annotation>
</sequence>
</group>
<choice>
<sequence>
<annotation><appinfo ...>
<dfdl:newVariableInstance ref='tns:flagVar' value='{ "i" }'/>
</appinfo></annotation>
<element name="i" type="xs:int"/>
<group ref='tns:flagGroup'/>
</sequence>
<sequence>
<annotation><appinfo ...>
<dfdl:newVariableInstance ref='tns:flagVar' value='{ "f" }'/>
</appinfo></annotation>
<element name="f" type="xs:float"/>
<group ref='tns:flagGroup'/>
</sequence>
</choice>
{code}
This still uses backtracking, but by sharing the flagGroup, including the
discriminator of the choice, this captures that the dispatch is done purely
based on the flagVar variable, and is done the same way in both branches of the
choice.
> forward-lookahead enhancement dfdlx:distance
> --------------------------------------------
>
> Key: DAFFODIL-2559
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2559
> Project: Daffodil
> Issue Type: New Feature
> Components: Back End, Front End
> Affects Versions: 3.1.0
> Reporter: Mike Beckerle
> Priority: Major
>
> In ticket DAFFODIL-641, an experimental forward-lookahead feature is added to
> Daffodil to enable use of choice flags that come a fixed distance ahead in
> the data.
> This is to handle cases from the format NATO STANAG 5516 (link16), where as a
> particular message format was extended to add new fields, some earlier fields
> in the message were no longer needed and were repurposed, resulting in fields
> earlier in the message the format of which depends on a flag that appears
> after them.
> Ticket DAFFODIL-641 details two things. A lookahead feature, and a second
> aspect that was not implemented, which is a dfdlx:choiceDispatchKeyPolicy
> which can be "immediate" (the default) or "deferred", meaning a lookahead
> behavior is needed as the choiceDispatchKey expression refers forward.
> This capability is possibly more than is needed, and introduces substantial
> complexity. For example the schema compiler must prove that the distance to
> the flag is constant for all possible parses.
> Alternatives are possible such as providing a function in the expression
> language which computes a constant distance between two sibling elements.
> E.g.,
>
> {code:java}
> dfdl:choiceDispatchKey='{
> xs:string(
> dfdlx:lookAhead(
> dfdlx:distance(., ../flag, "bits"),
> 8)
> )
> }'
> {code}
> In the above we see an extension function dfdlx:distance which is intended to
> compute a constant, and fails with a schema definition error if the distance
> between the two sibling elements is non-constant. The intention here is that
> this measures the distance from the end of the first argument to the start of
> the second argument.
> This function could be quite restrictive to only sibling elements within the
> same element parent so as to avoid a lot of complexity in Daffodil's schema
> compiler for this use case.
> Note that this same function might; however, be generalized to help compute
> things like dfdl:choiceLength, when the dfdl:choiceLengthKind is 'explicit'.
> This is another case where the schema author must compute an exact distance
> in the data requiring knowledge of the details of the format that would
> better be left to the schema compiler to figure out.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
