This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Is the expression unsignedInt("+123") an error? Although the merging of text on casts and constructor functions is a great improvement, the spec can still be read in two different ways. It hinges on the question of whether section 17.1.1 is applicable when casting from a string to a derived type. If 17.1.1 is applicable, then we apply whitespace normalization and the resulting string must be in the lexical space for the type. "+123" is not in the lexical space of xs:unsignedInt, so this construct is an error. If 17.1.1 is not applicable to derived types, then we find ourselves in section 17.2 (Casting to derived types) and thence 17.5, (Casting across the type hierarchy). This tells us to (a) cast "+123" to a string (which succeeds), (b) cast "+123" to an xs:integer (which succeeds), and (c) cast the integer 123 to an xs:unsignedInt (which also succeeds). So which is it? I don't think 17.1.1 makes sense unless it *is* applicable to casting from string to a derived type, because otherwise the notion of whitespace normalization is meaningless - the distinctions between whitespace handling for different target types only make sense where the target type is derived from string. So the conclusion is that 17.1.1 should not be a subsection of 17.1 (Casting from Primitive Types to Primitive Types) and that some better introductory material is needed at the start of section 17 telling you which section to turn to for each particular case. Michael Kay
After having discussed this issue with my constituency, we feel that in the given case of casting to numeric types, we should allow xs:unsignedInt("+13") (taking the cast to base type/down-cast approach. However, in the general case, where the target type's lexical and value space are aligned, we agree that patterns need to be checked... This is just another consequence of allowing patterns on types where the lexical and value space are not the same.
The working group discussed this and decided by a majority that we should make casting from string (and, by implication, constructor functions taking a string argument) consistent with schema validation: that is, if the target type is a type derived by restriction using a pattern, the source string should be checked against the pattern. This means that xs:unsignedInt("+123") becomes an error. Similarly, for a target type derived from boolean whose pattern allows only "true" and "false", casting from "0" or "1" would be an error. As you were present during the discussion, I will mark the issue as closed.
I am reopening this bug because the resolution does not seem to be adequately reflected in the PR document. It is still unclear, when you start reading section 17, that for casting from string to untypedInt you should turn to section 17.1.1 and not to section 17.2, and you still get different answers depending on which section you turn to. See bug #4023 against the test suite.
On the Dec 12, 2006 telcon the WGs decided that this bug can be closed by adding a sentence at the end of section 17 that says, in effect, "when casting from xs:string the semantics discussed in 17.1.1 apply regardless of target type".
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.