[DFDL-WG] Action 186: Re: DFDL Statement Evaluation Timing (Assert, Discriminator, SetVariable, NewVariableInstance)

[Mike Beckerle]

(Missed the CC of the whole WG.  Here it is.)

On Tue, Nov 20, 2012 at 6:49 AM, Steve Hanson <smh at uk.ibm.com> wrote:

> Hi Mike
>
> I have incorporated all this into Errata v011. A couple of comments:
>
> - You use 'parse error' in a few places where correct term is 'processing
> error'
>

I try to say parse error in a parsing specific context, and processing
error when something applies both parsing/unparsing, but obviously I blow
it sometimes.

Doesn't the spec say a parse error is a parse-specific processing error?


> - I think your new section 7.10 should be in section 9, as it is talking
> about order of execution and consequences of failure which are introduced
> in section 9.
>

Sounds fine to me. I just picked one possible logical spot.


>
> - Regarding "*It is also a processing error to read any variables defined
> by any dfdl:newVariableInstance statement evaluations that failed, or to
> read any variables set by any dfdl:setVariable statements that failed.* ",
> can you give a scenario where the processor can get into this situation?
>
>
Sure. I was just having to implement this the other day, which is where
this notion came from.  It certainly requires scrutiny.

Imagine a big complex sequence type.

There's a discriminator, but it involves a complex expression, perhaps more
than one field is involved in the calculation (e.g., if either this or
that, then we're on a B-type record) however, the structure has substantial
parse complexity beyond just identifying the two fields. Real work to do to
parse it.

The discriminator expression could be expressed in terms of variables just
because it is a complex calculation. I think this will be common in XPath
since it has no native local variables in the expression language people
will use DFDL variables just to avoid having to repeat large complex XPath
sub-expressions.

That's ok, because if the discriminator calculation is to succeed, then
those setVariable expressions would also have to succeed just as if the
discriminator were expressed as a bigger more complex nested expression
without variables.

But, there could also be OTHER setVariable statements in the mix, unrelated
to evaluating the discriminator. Those might fail if the whole parse
failed. The parts of the structure they depend on might not have been
successfully parsed at all.

We don't want to require implementations to know which setVariable
statements are needed for the discriminator and which are not, so we have
this simpler strategy where we can attempt them all. If one fails, we save
the error. Then when we get to evaluating the discriminator, it can still
succeed, i.e., evaluate to true and resolve the PoU, so long as it doesn't
need any of the failed setVariables. Then we fail with the saved error from
whichever setVariable statement failed.

...mikeb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20121120/5d76ad7e/attachment.html>