Did you get a response about this?
This may indicate a bug in Daffodil. To my eye your schema looks correct. I
think ../../Type should be the right path for those discriminators.
The best workaround is change to a choice by dispatch so you won't use
discriminators at all.
The second workaround is to put the discriminators on a sequence that
appears before the elements in each choice branch.
There's a small trick to this:
Not this in each branch:
<sequence>
annotation with discriminator
element of the branch
</sequence>
rather you must do:
<sequence>
<sequence> <!-- inner sequence to hold discriminator -->
annotation with discriminator
</sequence>
element of the branch
</sequence>
This inner sequence is needed because otherwise the discriminator will
evaluate at the END of the sequence i.e., after the element.
(Section 9.5 of the DFDL spec says that discriminators on a sequence
evaluate at the END of the sequence. DFDL implementations can hoist this to
earlier when the behavior would not be changed, but Daffodil does not do
that optimization. Personally I think this was a mistake in DFDL as it
violates top-down left-to-right default behavior. But it is easily worked
around by the inner sequence trick.)
On Thu, Apr 4, 2024 at 9:11 AM Larry Barber <larry.bar...@nteligen.com>
wrote:
> I’m having a problem with the attached schema.
> In the discriminators (lines 44 & 51), I cannot get Daffodil to access the
> value of *Type* (line 34).
>
> When I tried *../Type*, it says valid options are *P_INT32* & *P_UINT32*,
> I figured I needed to go back another level, but *../../Type* doesn’t
> work either. At this point it says valid options are *Msg_ID* &
> *Parameter*, which are too far back!
>
> However, line 37 has no problem accessing *Length* (line35).
>
> Anyone have an explanation for this? …or even better, a solution?
>
>
>
