I think this is a bug that seems to be caused by your P_INT32 and P_UINT32
elements being arrays (maxOccurs="unbounded"). If you add a sequence around each
of these arrays it seems to fix it, and you can reference Type using
"../../Type" (with two up-steps).
Note that a more efficient solution would be to remove your discriminators and
use choiceDispatchKey/choiceBranchKey, e.g.
<xs:choice dfdl:choiceDispatchKey="{ ../Type }">
<xs:sequence dfdl:choiceBranchKey="1">
<xs:element name="P_INT32" ... />
</xs:sequence>
<xs:sequence dfdl:choiceBranchKey="2">
<xs:element name="P_UINT32" ... />
</xs:sequence>
</xs:choice>
Note that in with this approach we only need a single up-step to reference
../Type, since it is evaluated outside of the P_INT/UINT elements.
On 2024-04-04 09:11 AM, Larry Barber 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?
