- From: <bugzilla@jessica.w3.org>
- Date: Wed, 01 Apr 2015 22:40:40 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26865 --- 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 rules: * 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 unchanged. 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