January 2025 - dfdl-wg - lists.ogf.org

Reminder for Agenda Topics for Workgroup call on 2024-06-13
by Mike Beckerle 05 May '25

05 May '25

Please send along any agenda topics you wish discussed on our next call which is next week. (If you are already aware you will be not attending, send that along as well) I do have one agenda topic to cover which is ISO document creation. I'll circulate a separate email introducing the topic.

1 4

Minutes from 2025-01-09 DFDL Workgroup Call
by Mike Beckerle 09 Jan '25

09 Jan '25

I've written these up here: https://github.com/OpenGridForum/DFDL/blob/master/calls/2025/2025-01-09_DFD… Comments and anything I missed welcome. You can edit the document, or reply to this email and I'll incorporate.

2 2

Clarification needed: multiple assert statements evaluation order
by Mike Beckerle 09 Jan '25

09 Jan '25

Given this DFDL annotation on an xs:sequence <xs:appinfo source="http://www.ogf.org/dfdl/"> <dfdl:assert test="..." /> <dfdl:discriminator test="..." /> <dfdl:assert test="..." /> </xs:appinfo> The spec seems silent about the evaluation order among these 3 statement annotations. Let's call them A, B, C. First, the spec makes it clear that the discriminator B could be evaluated earlier than either assertion, and even before some of the sequence content. This is to allow optimization by a DFDL implementation. The spec is also clear that even if the parse of the sequence content fails, discriminator B is evaluated (with the infoset being the state at the time of the failure). Again this is to ensure the behavior matches that of an optimizing DFDL implementation. But let's assume an implementation does no such optimization. I believe these evaluation orders are legal for the 3 statements after the sequence content has been parsed: A, B, C - if A fails, we do know B must still be evaluated. B, A, C - this is the minimum sort of hoist/optimization, doing the discriminator before the asserts. Questions: 1) Are any other orders of evaluation allowed? 2) If evaluation of A fails, do we still evaluate assertion C? (My hope is the answer here is no, because that allows consecutive asserts to build on each other's assumptions. But the spec is unclear.) 3) Can users depend on the failure of A to generate a message output? (ex: if the assert has a message attribute, can we state that this message will somehow be exhibited or logged by the implementation, unless the failure is suppressed by backtracking at a point of uncertainty) If A fails, the spec does say that B must still be evaluated. But if A fails, will C be evaluated? Mike Beckerle Apache Daffodil PMC | daffodil.apache.org OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Owl Cyber Defense | www.owlcyberdefense.com

2 3