Was a bug report created for the original error?

On Wed, Apr 17, 2024 at 5:13 PM Larry Barber <larry.bar...@nteligen.com>
wrote:

> Yes, Steve helped me with your best workaround, but the <sequence> change
> worked as well.
>
>
>
> *From:* Mike Beckerle <mbecke...@apache.org>
> *Sent:* Wednesday, April 17, 2024 5:08 PM
> *To:* users@daffodil.apache.org
> *Subject:* Re: No element corresponding to step {}Type found
>
>
>
> 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?
>
>
>
>

Reply via email to