Tim and I have discussed this and we are ok with making these situations schema definition errors rather than processing errors. We've not been able to find a realistic use case where an expression failing in this manner could legitimately be interpreted as failing to discriminate a point of uncertainty. It almost certainly indicates a problem withe the expression or an ambiguity with the model. For example, in the sequence case, the modeler can always return a single element by using a predicate in the expression (eg {../count[1]} ) 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: 19/01/2012 01:33 Subject: [DFDL-WG] Issue 163: Expressions returning ES - type of error when expression returns wrong type. Sent by: dfdl-wg-bounces@ogf.org I reviewed section 23. The last paragraph of 23.3 is inconsistent with the rest of the section. Suggested revised wording: The result of evaluating the expression must be a single atomic value of the type expected by the context, and it is a schema definition error otherwise. Some XPath expressions naturally return a sequence of values, and in this case it is also schema definition error if an expression returns a sequence containing more than one item. If the expression returns an empty sequence it will be treated as returning nil. -- 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