Hi Tim I've made some minor corrections to your summary of the problem. If the user restructures his model to wrap the sequences in elements then the problem goes away. So I think we should keep the solution to this as simple as we can while not being unnecessarily restrictive. 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: Tim Kimber/UK/IBM@IBMGB To: dfdl-wg@ogf.org Date: 13/04/2012 10:54 Subject: [DFDL-WG] How to choose the correct choice branch when serializing Sent by: dfdl-wg-bounces@ogf.org There is an interesting edge case which arises when the serializer encounters a choice group. A DFDL xsd is structured as follows: <root> <choice> <sequence> <firstname/> <lastname/> <postcode/> </sequence> <sequence> <lastname/> <telephoneNumber/> </sequence> </choice> </root> Note that both branches of the choice are sequences, not elements. The infoset is <root> <lastName/> <telephoneNumber/> </root> The likely action of the serializer is: - pick the first branch of the choice ( because it contains lastname ) - output the default value of firstname ( assuming that firstname has minOccurs = 1 and has a default ) - output lastname - issue a processing error because telephoneNumber is found in the info set but is not in the first branch. ...but from the infoset the user clearly intended: - select the second branch of the choice and successfully process the entire info set The DFDL specification does not state what the behaviour should be. I think the options are: a) state explicitly that the serializer will choose the first branch that contains a matching element, regardless of minOccurs b) invent a new rule that causes the parser to back out of a branch and try another branch if there is a minOccurs error while processing the branch c) disallow sequences and choices as immediate children of a choice group Currently I'm leaning toward a) by process of elimination, for the following reasons: b) would make this scenario work, but I think it would impose a lot of work on implementers because it would require the serializer to do backtracking. c) would simplify a lot of things, but I think it's too restrictive - I can imagine complex data formats where is might be useful to have a choice as the direct child of a choice because the discrimination rules might be easier to express in a two-level structure. regards, Tim Kimber, Common Transformation Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 246742 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 -- 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