bitOrder can't have an expression. Only byte order.
On Wed, Nov 24, 2021 at 1:26 PM Adams, Joshua <jad...@owlcyberdefense.com>
wrote:
> I've been looking at this some more today and I'm not seeing an easy way
> to get the enclosing sequence/group's bitOrder and apply it to the
> NewVariableInstance runtime data. NVI has access to the
> AnnotatedSchemaComponent, which does have access to enclosing elements, but
> I don't think there is any access to the runtime data for the enclosing
> element. I suppose it would be possible to read the raw attributes from
> enclosing element but I'm not sure that would work well if bitOrder is
> defined as an expression.
>
> Josh
> ------------------------------
> *From:* Mike Beckerle <mbecke...@apache.org>
> *Sent:* Tuesday, November 23, 2021 3:27 PM
> *To:* dev@daffodil.apache.org <dev@daffodil.apache.org>
> *Subject:* Re: DAFFODIL-2587 - dfdlx:lookAhead from newVariableInstance
>
> 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
> >
>
