[Bug 26865] CastableAs653 and CastableAs654 should expect false instead of true


--- Comment #11 from Michael Kay <mike@saxonica.com> ---
Just a reminder that the test case (653) is

12 castable as d:canonicalDecimal

Section 19.3.1 rule 2 requires us to assess whether " SV is an instance of a
type derived by restriction from the same primitive type as TT."

I think this condition is ambiguous, and the ambiguity is the source of the
problem. The sentence is worded as if a type can only be derived by restriction
from one primitive type, and this is not the case since xs:decimal and
xs:integer are both primitive types (as we have defined the term), yet one is
derived by restriction from the other.

I think the intended meaning of saying that xs:integer (and xs:dayTimeDuration
etc) are primitive types for casting purposes is that for any non-abstract
atomic type T there is a primitive type P(T) which is the "nearest" primitive
type from which T is derived by restriction, and the rule cited above should
read "When P(ST) is the same type as P(TT)". In this case P(ST) is xs:integer
and P(TT) is xs:decimal, so rule 2 does not apply.

I suggest the following rewording of the rules in 19.3.1:

Casting a value to a derived type can be separated into four cases. In these

* xs:untypedAtomic, xs:integer and the two derived types of
xs:duration:xs:yearMonthDuration and xs:dayTimeDuration are treated as
primitive types

* for any atomic type T (other than xs:anyAtomicType), P(T) is the most
specific primitive type such that itemType-subtype(T, P(T)) is true.

The rules are then:

1. When ST is the same type as TT: the cast always succeeds, returning SV

2. When itemType-subtype(ST, TT) is true: this case is described in section
19.3.2 Casting from derived types to parent types.

3. When P(ST) is the same type as P(TT): this case is described in 19.3.3
Casting within a branch of the type hierarchy.

4. Otherwise (P(ST) is not the same type as P(TT)): this case is described in
19.3.4 Casting across the type hierarchy.

You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 1 April 2015 22:40:43 UTC