Ok, then to clarify, if I put a discriminator inside a branch of a choice with direct dispatch, that discriminator should simply confirm the direct dispatch selection of the choice dispatch key? I.e., it is ignored? So if I have two nested choices, the outer backtracks, the inner is choice by dispatch, then to discriminate the OUTER choice, I have to issue two discriminators in a row. The first is a noop because it applies to the inner choice. The second affects the outer choice? This would seem to be the implications of having the choice with direct dispatch be a PoU still. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | www.owlcyberdefense.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php> On Tue, Jul 14, 2020 at 4:08 AM Steve Hanson <smh@uk.ibm.com> wrote:
I don't agree, because unlike an array with a fixed number of occurrences, it is a *processing error* if the value of the expression does not match any of the dfdl:choiceBranchKey property values for any of the branches. Which currently causes backtracking because there is a PoU.
I consider direct dispatch as more like the use of dfdl:initiatedContent when resolving a choice.
This is not a behaviour that can be changed in DFDL 1.0, it would affect too many existing schemas. For example, IBM's DFDL schemas for SWIFT make heavy use of direct dispatch.
Regards
Steve Hanson
IBM Hybrid Integration, Hursley, UK Architect, *IBM DFDL* <http://www.ibm.com/developerworks/library/se-dfdl/index.html> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/> *smh@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848 mob:+44-7717-378890 Note: I work Tuesday to Friday
From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: DFDL-WG <dfdl-wg@ogf.org> Date: 13/07/2020 14:50 Subject: [EXTERNAL] [DFDL-WG] clarification needed: choice with direct dispatch is/is-not a PoU Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org> ------------------------------
Just like an array with a computed number of occurrences, I believe a choice with direct dispatch should have no PoU.
But the spec has this phrase "An xs:choice is always a point of uncertainty. It is resolved sequentially, or by direct dispatch."
Which suggests there is a role for asserts/discriminators in resolving a choice by direct dispatch even though there shouldn't be.
I think we should clarify this to "An xs:choice either is a point of uncertainty, or uses direct dispatch."
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | *www.owlcyberdefense.com* <http://www.owlcyberdefense.com> Please note: Contributions to the DFDL Workgroup's email discussions are subject to the *OGF Intellectual Property Policy* <http://www.ogf.org/About/abt_policies.php> -- 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