Michael Beckerle created DAFFODIL-2021:
------------------------------------------
Summary: Daffodil expressions for properties should not
auto-coerce to property type. Test BC000.
Key: DAFFODIL-2021
URL: https://issues.apache.org/jira/browse/DAFFODIL-2021
Project: Daffodil
Issue Type: Bug
Components: Middle "End"
Affects Versions: 2.2.0
Reporter: Michael Beckerle
Recently discovered that IBM DFDL properly detects an error in test BC000.
This test uses an element with this property:
{{{
dfdl:textBooleanTrueRep="{ 1*10 }"
}}}
DFDL spec section 23.3 says:
* Every property that accepts an expression states exactly what the expression
is expected to return. To ensure the returned value is of the correct type, an
expression must use XPath constructors or the correct literal values.
* No extra auto-casting is performed over and above that provided by XPath 2.0.
XPath 2.0 has rules for when it promotes types and when it allows types to be
substituted. These are in Appendix B.1 of the XPath 2.0 spec.
Note the use of 'must' in the first bullet.
Daffodil 2.2.0 actually knows this property wants a string, so compiles in an
automatic conversion of this number to a string. This is incorrect. It should
be insisting that the property expression return the proper type.
For portability the test has been modified to have:
{{{
dfdl:textBooleanTrueRep="{ xsd:string(1*10) }"
}}}
This of course passes both IBM DFDL and Daffodil.
However, the bug remains in Daffodil that the auto-conversion was inserted
rather than detecting what was, most likely, a user error. Writing a numeric
expression for textBooleanTrueRep, or most other string-valued properties is
almost certainly an error by the schema author, not something where they're
expecting a numeric value to be used for the string. So this is just going to
potentially match silly mistakes by schema authors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
