Thank you Mike and Steve!
To pick up on what Steve suggested:
<xs:sequence dfdl:choiceBranchKey="0 6 7">
<xs:sequence dfdl:hiddenGroupRef="hidden-SPARE-5" />
</xs:sequence>
Is this correct:
If ENVIRONMENT/BitCode = 0, then unparsing will produce 00000
If ENVIRONMENT/BitCode = 6, then unparsing will produce 00000
If ENVIRONMENT/BitCode = 7, then unparsing will produce 00000
So, unparsing produces the wrong output when ENVIRONMENT/BitCode = 6 or
ENVIRONMENT/BitCode = 7, right?
I see what Mike is saying about inserting a non-hidden (bogus) element for the
hidden fields.
These are poor solutions. There’s got to be a better solution.
From: Steve Lawrence <[email protected]>
Sent: Friday, May 31, 2024 11:58 AM
To: [email protected]
Subject: [EXT] Re: Best way to design DFDL for a choice with multiple branches
that create hidden fields?
Note that in this specific case, since your hidden branches are all the same,
you can silence the warning by combining them into a single branch, e. g. .. .
<xs: sequence dfdl: choiceBranchKey="0 6 7"> <xs: sequence dfdl:
hiddenGroupRef="hidden-SPARE-5"
ZjQcmQRYFpfptBannerEnd
Note that in this specific case, since your hidden branches are all the same,
you can silence the warning by combining them into a single branch, e.g.
...
<xs:sequence dfdl:choiceBranchKey="0 6 7">
<xs:sequence dfdl:hiddenGroupRef="hidden-SPARE-5" />
</xs:sequence>
...
This way there is only one hidden branch so Daffodil will know that this branch
is the only option to unparse if there is nothing in the infoset where this
choice is.
But this doesn't work if any of your hidden branches are different (e.g. one was
SPARE-5 and another was SPARE-6). In that case, you would need to do what Mike
suggests and have some non-hidden element to let Daffodil know whether to
unparse a SPARE-5 or -6.
On 2024-05-31 11:26 AM, Mike Beckerle wrote:
>
> There is no way in DFDL v1.0 to make choices at unparse time that are not
> guided
> by what the contents of the non-hidden infoset are.
>
> If all this stuff is hidden it is not in the infoset for consideration on how
> to
> unparse it.
>
> That means that somehow the unparser has to figure out, from the infoset that
> is
> present, what part of the hidden infoset it needs to create.
>
> The dfdl:choiceDispatchKey and dfdl:choiceBranchKey are parse-time-only. They
> are not evaluated at unparse time.
>
> There is no dfdlx:choiceDispatchKey/ForUnparse/ (though I have considered it.)
>
> I suspect that the only thing you can do is put some non-hidden element in
> each
> branch of the choice. That way the unparser can know what branch to unparse.
> Everything else about that branch of the choice can be hidden. This can just
> be
> a marker element with no content, but it needs to be the first thing in each
> branch.
>
>
>
> On Fri, May 31, 2024 at 7:17 AM Roger L Costello <[email protected]
> <mailto:[email protected]>> wrote:
>
> I have an xs:choice which has 3 branches that create hidden fields.
> Daffodil
> generates this warning message:____
>
> __ __
>
> /Multiple choice branches with no required elements detected and the
> infoset
> does not specify a branch, selecting the first branch for unparsing.____/
>
> __ __
>
> What is the best way to design DFDL for this situation?____
>
> __ __
>
> ____
>
