[DFDL-WG] clarification needed: unparsing and hidden group choices and choices with dfdl:choiceDispatchKey

[Mike Beckerle]

So interesting issue. Comes up as part of our experience implementing the
advanced expression language features: hidden groups, and computed elements.

We have hidden groups in DFDL.

If a xs:choice is inside a hidden group, then by definition, when
unparsing, elements corresponding to some branch of the choice are not in
the Infoset.

DFDL spec clearly states that dfdl:outputValueCalc is not allowed on the
head of a choice branch.

But elements inside hidden groups must have dfdl:outputValueCalc, or a
default value, otherwise there's no way for them to be filled in as part of
the augmented infoset.

So the only way a choice can be inside a hidden group is if the head of the
choice branches have default values.

This is not sufficient.

I do not think it was our intention to make hidden groups incapable of
holding things complex enough to contain a choice. Rather, the point is to
be able to hide things that have excess complexity needed only for
parsing/unparsing, so that they need not appear in the final Infoset.

So if a choice is allowed inside a hidden group, then a mechanism is needed
by which when unparsing a choice branch is selected based on values of
other parts of the Infoset, and then the elements of that branch are
computed and added to the augmented infoset.

Note that without hidden groups, this problem never arises, as the Infoset
always has to take a position on choice branches by having an unambiguous
element in it.

There are 3 cases:

   1. unparsing an xs:choice where for parsing, each branch has a
   discriminator, or is resolved by the simple "first successful parse" rule.
   2. unparsing an xs:choice with dfdl:choiceDispatchKey
   3. unparsing xs:choice with dfdl:initiatedContent='yes'


For all cases, I suggest we must remove the restriction on
dfdl:outputValueCalc being disallowed on choice branch head.

For (1). First branch where the branch can be constructed successfully is
added to the augmented infoset. This is a case where an unparse error is
non-fatal, and causes a form of unparser backtracking through alternatives.
Branches would be attempted in schema order.

For (2) I suggest dfdl:unparseChoiceDispatchKey, evaluated at unparse time
only. Produces a choice branch key.  That choice branch is then
constructed, and default values or dfdl:outputValueCalcs are used to fill
in values. (BTW: this is the driving use case we have in Daffodil for this
issue.)

For (3).... I have no specific solution. I think it may not actually be a
separate case and has to be treated as (1) or (2).

Comments/Discussion?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20170127/7eaf24d7/attachment.html>