This is the hairy edge of DFDL language evolution. Possibly a dfdl:choiceDispatchKeyForUnparse property, and similarly a dfdl:occursCountForUnparse property, which are explicitly evaluated at unparse time to control choice branches and optional/array existence when unparsing.
We will have to add extension properties to try these ideas out. But some people would just say this is too much transformation for a "format description" language. Artifacts of the representation cannot always be suppressed. We (Owl) ran in to this same issue in a few formats. Asterix has a variable-length bit vector at the start of each message, and we have no way to minimize the length of this bit vector based on which of all the optional fields follow it. So if you parse an Asterix message, we can populate the Infoset based on which fields are indicated present in the bit vector. But then suppose you transformed the data by removing an optional field. Unparsing that modified message properly may require you to shorten the bit vector, as it may have more than 8 trailing zero bits, in which case it can be one byte shorter. That we cannot express in DFDL we think. There is no way, hidden or not, for unparsing to remove an element from the infoset because we are somehow able to determine it is not needed in the unparsed representation. On Fri, May 31, 2024 at 12:07 PM Roger L Costello <[email protected]> wrote: > 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] <[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?____ > > > > > > __ __ > > > > > > ____ > > > > > > >
