Presumably the same issue would arise if dfdlx:lookahead was called from a
setVariable annotation on a sequence also.
I happen to know there is a requirement for this to reach into data at
boundaries that are NOT byte boundaries, so the dfdl:bitOrder really does
matter for this function.
I claim the right thing is for the bitOrder to come from the model group on
which the newVariableInstance or setVariable is residing.
My reasoning is that if you call dfdlx:lookAhead from the choiceDispatchKey
expression of a choice, the bitOrder is that of the choice model group.
That's how it works today.
There should be no difference between expressing a dfdl:choiceDispatchKey
that directly uses a dfdlx:lookAhead call, and one that does so by way of a
new variable instance.
<xs:choice>
<xs:annotation>
<xs:appinfo ...>
<dfdl:newVariableInstance ref="a:flag" defaultValue='{
dfdlx:lookAhead(....) }'/>
<dfdl:choice choiceDispatchKey='{ $a:flag }'/>
</xs:appinfo>
</xs:annotation>
.... choice branches here
</xs:choice>
So I think the right answer is to just require the enclosing model group's
model-group runtime data object be passed down to the newVariableInstance
or setVariable primitive parser/unparser.
On Tue, Nov 23, 2021 at 1:05 PM Adams, Joshua <jad...@owlcyberdefense.com>
wrote:
> I've been taking a look at this bug and am trying to figure out what the
> correct behavior for this situation would be. Currently, attempting to
> call dfdlx:lookAhead as part of an expression for the default value of a
> newVariableInstance will result in a UsageError being thrown when
> attempting to get the bitOrder, as the VariableRuntimeData is descended
> from NonTermRuntimeData.
>
> It doesn't seem unreasonable to want to use lookAhead from inside a
> newVariableInstance, but I'm not sure there is an easy way to get the
> parent sequence/element that contains the annotation where the
> newVariableInstance is defined. I noticed that for elements when the
> expression for byteOrder isn't defined, it just defaults to BigEndian with
> comments stating that this likely means that the element is likely
> hexBinary, in which case the byte order should be ignored. I don't know if
> it makes sense to do something like this and just defauilt bitOrder for
> VariableRuntimeData's to MSBF, as from the examples of lookAhead that I've
> seen involve looking into a hexBinary element.
>
> Thoughts?
>
> Josh
>
