Bug #4820


Expression `[1,2,3] castable as xs:integer` returns true

Added by Michael Kay over 1 year ago. Updated over 1 year ago.

XPath conformance
Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
10, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:


Raised by Ghislain Fourny on xquery-talk list.

Test case CastableAs664 added to QT3.

Actions #1

Updated by Michael Kay over 1 year ago

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.

Actions #2

Updated by Michael Kay over 1 year ago

  • 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.

Actions #3

Updated by Michael Kay over 1 year ago

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.

Actions #4

Updated by Michael Kay over 1 year ago

  • Status changed from In Progress to Resolved
  • Applies to branch 10, trunk added
  • Fix Committed on Branch 10, trunk added
Actions #5

Updated by O'Neil Delpratt over 1 year ago

  • 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