DPath not finding obvious type errors involving constants at compile time

See test test_expression_type_error2()

The test has an expression which clearly is erroneous.

<xs:element name="e3" type="xs:int" dfdl:inputValueCalc="{ 2.5 }" />

where a decimal/floating point constant is given as the value for an xs:int type element.

Current behavior just truncates and produces the value 2.

This is the right semantics for the xs:int(...) function call.

This from the XPath functions spec:

If ST is xs:decimal, xs:float or xs:double, then TV is SV with the fractional part discarded and the value converted to xs:integer. Thus, casting 3.1456 returns 3 and -17.89 returns -17. Casting 3.124E1 returns 31. If SV is too large to be accommodated as an integer, (see [XML Schema Part 2: Datatypes Second Edition] for ��implementation-defined�� limits on numeric values) an error is raised [err:FOCA0003]. If SV is one of the special xs:float or xs:double values NaN, INF, or -INF, an error is raised [err:FOCA0002].

Right now, if a value is returned by an expression via inputValueCalc, then it is converted to the type of the element in exactly the same way that an argument to a function is converted.

This leads to the strange anomalies like test_expression_type_error2() where there is a clear mistake by the schema author.

Fixing this so we can issue an SDE or warning requires that the DPath constant folding be enhanced substantially so that it can not only determine if an entire expression is a constant or not, but sub-expressions within an expression.