(Missed the CC of the whole WG. Here it is.) On Tue, Nov 20, 2012 at 6:49 AM, Steve Hanson 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