This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This issue is raised by a test suite problem: see bug #26865. Simply stated: section 19.1 says "These four types (including xs:integer) are not primitive types but they are treated as primitive types in this section." But what is "this section"? Is it 19.1, or the whole of section 19? In particular, is xs:integer a primitive type for the purposes of section 19.3.1? The question affects which of the following two rules applies when casting from xs:integer to a type derived from xs:decimal: (2) When SV is an instance of a type derived by restriction from the same primitive type as TT. This is described in 19.3.3 Casting within a branch of the type hierarchy. (3) When the derived type is derived, directly or indirectly, from a different primitive type than the primitive type of ST. This is described in 19.3.4 Casting across the type hierarchy. The difference determines whether the pattern facet on the target type is tested against the canonical lexical representation as defined by the xs:integer type, or the canonical lexical representation as defined by xs:decimal. If (as in this test case) the pattern facet requires a decimal point, then in one case casting succeeds, in the other case it fails.
Arguing from first principles rather than trying to interpret the text of the spec, I think the pattern facet should be tested against (a) if we're casting from string, against that string (b) otherwise, against the "canonical lexical representation of the target value assuming casting succeeds". On this basis, in the relevant test, casting should succeed, which is the result we get if we treat xs:integer as a primitive type for the purposes of 19.3.1.
I think there is an additional, much more convincing, reason why casting between types derived from integer and decimal should follow 19.3.4 (casting across the type hierarchy) rather than 19.3.3 (casting within a branch). Consider 12.01 cast as xs:positiveInteger Since (12.01 cast as xs:integer) succeeds, it seems reasonable that 12.01 cast as xs:positiveInteger should also succeed. This will be true only if we follow 19.3.4. Furthermore, if after this length of time we are clarifying an ambiguity in the spec, we should lean towards the more permissive interpretation, i.e. not stopping things from working that on one reading of the spec should currently work.
In comment 0: > In particular, is xs:integer a primitive type for the purposes of section 19.3.1? Yes. The second sentence of 19.3.1 says: "Note that xs:untypedAtomic, xs:integer and the two derived types of xs:duration:xs:yearMonthDuration and xs:dayTimeDuration are treated as primitive types."
Following WG discussion yesterday: the WG agreed that no substantive changes were needed to the spec; however, clarifications might be appropriate given that several WG members had misread it. I have therefore made editorial changes to the casting section to emphasize the specialized use of the term "primitive type" throughout section 19, in particular by creating a definition for it, and linking to that definition whenever the term is used.