[DAFFODIL-2021] Daffodil expressions for properties should not auto-coerce to property type. Test BC000.

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.2.0
• Fix Version/s: 2.3.0
• Component/s: Middle "End"
• Assignee: Steve Lawrence
• Reporter: Mike Beckerle
• Created: 21/Nov/18 04:25
• Updated: 20/May/21 12:34
• Resolved: 11/Jan/19 14:05

Description

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.