[
https://issues.apache.org/jira/browse/DAFFODIL-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Lawrence resolved DAFFODIL-2021.
--------------------------------------
Resolution: Fixed
Fix Version/s: 2.3.0
Fixed in commit a2f56a3f44d307a138fb7a4614f873120e186d63
> 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
> Assignee: Steve Lawrence
> Priority: Major
> Fix For: 2.3.0
>
>
> 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)
