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

[Steve Hanson]

Mike

In the call we said that you would look at this and "come up with a 
minimum statement of behaviour for potential inclusion in spec". I thought 
I would refresh my memory on the issue.

A couple of observations:

Your case 1). This is what we would do anyway for a missing choice - see 
9.4.3.2.

Your case 2). This has made me wonder whether we should have updated 
9.4.3.2 when we added the erratum for direct dispatch choice, to do as you 
propose for the non-hidden case.

Your case 3). I think is actually case 1).

I think allowing dfdl:outputValueCalc on the head of a choice branch works 
as long as it acts just like a default value when unparsing, with no 
effects on choice resolution. 

Regards
 
Steve Hanson
IBM Hybrid Integration, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday 



From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
Date:   27/01/2017 18:48
Subject:        [DFDL-WG] clarification needed: unparsing and hidden group 
choices and choices with dfdl:choiceDispatchKey
Sent by:        "dfdl-wg" <dfdl-wg-bounces at ogf.org>




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 unparse" 
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?


--
  dfdl-wg mailing list
  dfdl-wg at ogf.org
  https://www.ogf.org/mailman/listinfo/dfdl-wg

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20191213/d8daf374/attachment.html>