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