Hi Mike I believe the rule is that an assert/discriminator expression is evaluated "as soon as it can be". In IBM DFDL, we try to evaluate an expression when it is encountered, and if it can't be evaluated at that time because it references element(s) that do not appear in the infoset, the parser continues but the expression manager registers an interest in the element(s). The expression manager gets notified when the element(s) appear in the infoset and the expression is re-evaluated at that time. If the parser gets to the end of the scope for the assert/discriminator and it is still not evaluated, it is an error. (Tim please correct any mis-information). Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org Date: 13/09/2012 16:32 Subject: [DFDL-WG] assert and discriminator - no more before/after Sent by: dfdl-wg-bounces@ogf.org I am looking in the spec for guidance about the evaluation order of assert statements. We used to have before/after control properties, but eliminated them. If I annotate a simpleType'd element with an assert that says { . eq 'x' }, that of necessity references the current value, so must execute after the value has been computed. If on the other hand I annotate a complexType element with a discriminator that says { ../flag eq 'C1' } then this of necessity must execute before I go after the contents because the whole point is to evalutate the discriminator first. Did we ever articulate exactly what the rules are here about order of evaluation? Thanks for reminders ..mikeb -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- dfdl-wg mailing list dfdl-wg@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