Bug #4820
closed
Expression `[1,2,3] castable as xs:integer` returns true
Category:
XPath conformance
Applies to branch:
10, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:
Description
Raised by Ghislain Fourny on xquery-talk list.
Test case CastableAs664 added to QT3.
CastableExpression.typeCheck() has the logic
if (converter.isAlwaysSuccessful() && !allowsEmpty() && operand.getCardinality() == StaticProperty.ALLOWS_ONE) {
return Literal.makeLiteral(BooleanValue.TRUE, this);
}
This wrongly assumes that if the value of the operand is a singleton, then its atomized value will also be a singleton.
- Status changed from New to In Progress
The code for CastableExpression has the comment:
// We need to take care here. The usual strategy of wrapping the operand in an expression that
// does type-checking doesn't work here, because an error in the type checking should be caught,
// while an error in evaluating the expression as written should not.
I think this suggests it was written before the spec was clarified to say that an error that occurs when atomizing the operand is treated as an error, not as a false result.
I'm therefore going to try doing a staticTypeCheck() call on the operand, with an expected type of xs:anyAtomicType.
By doing a "standard" call on staticTypeCheck with an expected type of xs:anyAtomicType*, we pass all the CastableExpr tests including the new one. There are two "wrong error code" results:
CastableAs666 and CastableAs668 both return FOTY0013 rather than XPTY0004.
These are recent tests and a careful reading of the spec shows that the expected error code is wrong, so I will fix the tests.
- Status changed from In Progress to Resolved
- Applies to branch 10, trunk added
- Fix Committed on Branch 10, trunk added
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 10.5 added
Bug fix applied to Saxon 10.5 maintenance release.
Please register to edit this issue
Also available in: Atom
PDF
.