This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1207 - Is unsignedInt("+123") an error?
Summary: Is unsignedInt("+123") an error?
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Proposed Recommendation
Hardware: All Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-04-05 08:42 UTC by Michael Kay
Modified: 2007-02-25 23:20 UTC (History)
0 users

See Also:


Description Michael Kay 2005-04-05 08:42:48 UTC
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
Comment 1 Michael Rys 2005-05-13 23:24:11 UTC
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.
Comment 2 Michael Kay 2005-07-21 19:23:13 UTC
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.
Comment 3 Michael Kay 2006-11-27 19:09:30 UTC
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.
Comment 4 Ashok Malhotra 2006-12-13 20:14:30 UTC
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".
Comment 5 Jim Melton 2007-02-25 23:20:50 UTC
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.