> I would expect this too, but I don't think it's what the spec says. In
> 3.3.4, Validation Rule: Element Locally Valid, it implies that <test
> xsi:type="xs:string">10</test> is valid if 10 is a valid xs:string (w=
hich 
> it
> is), provided that xs:string is validly derived from s2 (which it is). =
I
> can't see anything in the rules that causes the enumeration facet to be
> checked.

Ah, I understand. So xsi:type doesn't change the order of evaluation of a=
 
union's member types (as it is said in =A72.5.1.3 of XML Schema Part 2) b=
ut 
instead the value is validated against the given type (if it is a member 
type of the union).

This means that the constraining facets of the union are circumvented by =
the 
usage of xsi:type. Also <test xsi:type="xs:integer">540</test> would be=
 
perfectly valid. So using xsi:type for union types can make instance 
documents valid which wouldn't be valid otherwise. The allowed document s=
et 
isn't further restricted but extended.

Thank you, that helped me. So both tools are correct: The tool which only=
 
has the integer "10" in the value space of the union type and also the to=
ol 
which successfully validates <test xsi:type="xsd:string">10</test>. But=
 I 
would agree that it isn't reasonable because it contradicts the general 
philosophy followed in validation against simple types (which in all othe=
r 
cases only allows a restriction).

Cheers
Klaas