[DFDL-WG] Issue 163: Expressions returning ES - type of error when expression returns wrong type.

[Steve Hanson]

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 at uk.ibm.com
tel:+44-1962-815848



From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     dfdl-wg at 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 at 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 at 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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20120124/590620c2/attachment.html>