This was the subject of bug #1207 against the spec.

Bug #1207 was resolved as follows:

<resolution>
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.
</resolution>

It's not clear to me that the PR version of F+O completely reflects this resolution. If you read sections 17.2 and 17.5 they still imply that this cast succeeds. Section 17.1.1 implies that the cast fails, but 17.1 is about casting to primitive types so one could argue that it's not applicable and 17.2 takes precedence.

In any case, given the confused state of the spec it's hardly surprising if implementations are at variance...

fn-abs-more-args-023 also exhibits this problem, this time for xs:unsignedLong("-0")

(In reply to comment #1)
> If you read sections 17.2 and 17.5 they still imply that this cast
> succeeds.

I see in 17.5:

"If SV is an instance of xs:string or xs:untypedAtomic, check its value against the pattern facet of TT, and raise an error [err:FORG0001] if the check fails."

That seems fairly unambiguous.  Besides, I don't see how 17.5 is applicable, since it talks about when "When the ST and the TT are derived, directly or indirectly, from different primitive types".  Here ST is xs:string, which is not a derived type, as I understand it.

Then the question is what is the pattern facet of unsignedLong?  Unfortunately, the XML Schema specification doesn't explicitly specify this: It says that unsignedLong *has* a constraining pattern facet, but doesn't say what it is.  However, implicitly, a sign is clearly not allowed.

On the other hand, it is worth noting that the Working Draft 17 February 2006 of XML Schema 1.1 clearly does allow an optional sign.  It also fixes the editorial problems by explicitly specifying the pattern facet.

The final spec will clarify that when you cast from xs:string to xs:unsignedInteger, the section that applies is section 17.1.1. This states:

When casting from xs:string or xs:untypedAtomic to a derived type where the derived type is restricted by a pattern facet, the lexical form is first checked against the pattern before further casting is attempted (See 17.2 Casting to derived types). If the lexical form does not conform to the pattern, error [err:FORG0001] is raised.

which makes it clear that xs:unsignedInt('-123') is an error given XML Schema as currently defined.

The pattern facets for types such as xs:unsignedInt are given in the schema for schemas.

The text for unsignedInt and similar types makes statements like (3.3.22.1): 

unsignedInt has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39). For example: 0, 1267896754, 100000

However, there is no pattern facet in the schema-for-schemas that enforces this constraint. This is true in both the first and second editions of XML Schema 1.0.

Given the clarification in the F+O spec that section 17.1.1 applies to this cast, we have the statement "The semantics of casting are identical to XML Schema validation", which means that if validating "+123" as an unsignedInt fails, then casting it will also fail. So it becomes a question of which takes precedence: the cited text in XML Schema Part 2 section 3.3.22.1, or the schema for schemas.

If you follow the rules for validating an instance against a schema, you get to Validation Rule: Datatype Valid in Schema Part 2 section 4.1.4, and this invokes validation of the lexical representation against the pattern facet, but not against any English text describing a built-in data type. On the other hand, this interpretation would make no sense in the case of primitive data types, because the English text describing the lexical form of (say) xs:float is all we have, and it's clearly intended to be normative.

So I think this needs clarification from the Schema WG. Meanwhile, we can guess what answer we might get if we note that XML Schema 1.1 explicitly permits "+123" and "-0" in the lexical space of unsignedInt and similar types.

Note also the text at the start of XML Schema 1.0 part 2 section 3.3:

<quote>
This section gives conceptual definitions for all ·built-in· ·derived· datatypes defined by this specification. The ... complete definitions of the ·built-in·  ·derived· datatypes are provided in Appendix A Schema for Datatype Definitions (normative) (§A).
</quote>

This text makes it fairly clear that the definitive rules for derived types such as xs:unsignedInt are in the S4S rather than in the English prose, and it follows that "+123" is therefore a legal representation of xs:unsignedInt.

Original report is now invalid, as comments to this report and bug #1207 reveals.