[
https://issues.apache.org/jira/browse/DAFFODIL-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415620#comment-17415620
]
Mike Beckerle commented on DAFFODIL-2559:
-----------------------------------------
One problem this technique can't address is that the flag field or any of the
other repeated fields in the flagGroup may also be used elsewhere later, and by
repeating it per the above described schema (prior comment), a path like
"../flag" is now ambiguous since there are two flag fields, one defined in each
branch of the choice. Daffodil (as of 3.1.0) is going to complain about this
"query-style expression".
Hiding the flag field (or its siblings) so that it cannot be referenced, and
then computing a corresponding field after the choice may work, but adds yet
more complexity.
Maybe some kind of layering capability is needed?
> 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)
