- From: Klaas Dellschaft <klaasd@uni-koblenz.de>
- Date: Fri, 31 Dec 2004 17:29:11 +0100
- To: "Michael Kay" <mike@saxonica.com>, "'George Cristian Bina'" <george@oxygenxml.com>, "'Xan Gregg'" <xan.gregg@jmp.com>
- Cc: <xmlschema-dev@w3.org>
> 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
Received on Friday, 31 December 2004 16:29:17 UTC