Re: Handling the enumeration facet

> 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 (which 
> 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 §2.5.1.3 of XML Schema Part 2) but 
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 set 
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 tool 
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 other 
cases only allows a restriction).

Cheers
Klaas