Page History

...

This breaks the rule that when variables are evaluated, things they reference must have already been evaluated. Basically, when we delay evaluating the OVC for len we are suspending anything that depends on len having a value as well.

In addition, since these setVariable and newVariableInstance expressions are forward referencing, they cannot be evaluated when parsing. Hence, some information is needed to tell the DFDL parser not to evaluate these expressions when parsing.

fn:error(...) Function needed to issue errors when unparsing

...

TBD: implementation of unordered sequences is raising issues here. Just restricting this usage may be the right choices.

See JIRA DAFFODIL-1159

Unparsing and Choice Groups, Especially Hidden Choice Groups

There are two problems related to unparsing and xs:choice.

Problem 1: dfdl:outputValueCalc that must refer into a child element inside a xs:choice

Example of this is this fragment of a messaging format where each message has a label and sublabel element that indicate which message it is. Logically, users think of, and expect to find the label and sublabel elements within the message structure, but we must have them before the element in order to use an xs:choice with dfdl:choiceDispatchKey to determine the message.

The alternative, using discriminators inside each message format, is too slow, a dfdl:choiceDispatchKey, is simply required and actually expresses the format better, since it captures the uniform way all messages are determined. Separate discriminators could all work the same way, but there are no guarantees.

Here's the Infoset, without any hidden groups being used:

<label>3</label>
<sublabel>2</sublabel>
<message_3.2> <!-- choiceDispatchKey on label and sublabel above selects specific message element -->
    <label>3</label> <!-- use IVC to derive from outer label -->
    <sublabel>2</sublabel> <!-- use IVC to derive from outer sublabel -->
    ....

If we want the outer label and sublabel elements to use dfdl:outputValueCalc, symmetric to the IVC when parsing, then the path needs to have a wildcard in it:

<element name="label" type="xs:int"
  dfdl:outputValueCalc="{ ../*/label }" />
<element name="sublabel" type="xs:int"
  dfdl:outputValueCalc="{ ../*/sublabel }" />

Problem 2: Choices inside hidden groups

The DFDL Spec discussion of unparsing choices assumes an element that appears within one of the branches of the choice exists in the infoset. This isn't necessarily the case. If the choice is part of a complex representation that is hidden, then no infoset element will exist corresponding to any branch.

The problem can be phrased simply as: Depending on some value, choose a representation.

The classic example of this is a "smart string" representation.  This is a representation that tries to avoid wasted space for short strings. For example, uses a 1-byte length field for strings from length 0 to 127, and a 4-byte length for longer strings.

Logically, the value is just a text string, but it has a complex representation, and so a hidden group to hide that complex representation is natural.

In DFDL we'd like to have a hidden group that holds the specifically short length field, or the longer length field. This is a choice.

<!-- in the hidden group -->
<choice>
   <element name="shortLen" type="xs:byte" dfdl:outputValueCalc="{ fn:length(../s) }" />
   <element name="longLen" type="xs:int" dfdl:outputValueCalc="{ - fn:length(../s) }"/>
</choice>
<!-- after the hidden group -->

<element name="s" type="xs:string"
  dfdl:length="{ if (fn:exists(../shortLen)) ../shortLen
                         else  0 - ../longLen }"/>

When unparsing we have in the infoset only the string 's'.  We have no place to express that we must scrutinize the length of 's' in order to decide whether the representation should use a shortLen length, or a longLen length.

One suggestion is to create symmetric unparse-time discriminators, and an unparser-specific version of dfdl:choiceDispatchKey and dfdl:choiceBranchKey. These could then refer to the logical infoset element 's' and determine how to resolve the choice.

Thusfar we don't have a use case where the generality of discriminators is needed versus what can be done with the unparse-time equivalent of dfdl:choiceDispatchKey.