- From: Michael Kay <mike@saxonica.com>
- Date: Fri, 31 Dec 2004 14:44:02 -0000
- To: "'George Cristian Bina'" <george@oxygenxml.com>, "'Xan Gregg'" <xan.gregg@jmp.com>
- Cc: <xmlschema-dev@w3.org>, <klaasd@uni-koblenz.de>
> Xan Gregg wrote: > > > > The example is not valid. The enumeration needs to be done in a > > separate step, as follows: > > > > <xsd:simpleType name="s1"> > > <xsd:union memberTypes="xsd:integer xsd:string"/> > > </xsd:simpleType> > > > > <xsd:simpleType name="s2"> > > <xsd:restriction base="s1"> > > <xsd:enumeration value="10"/> > > </xsd:restriction> > > </xsd:simpleType> > > > > Now it's more clear that the value space has only the > integer 10, since > > the lexical value "10" corresponds to the integer 10 in s1. > > > >> But you can change the sequence of evaluation in an > instance document > >> with > >> the attribute xsi:type. > > > > > > If test is declared to have type s2, I would expect: > > > > <test xsi:type="xs:integer">10</test> <!-- valid --> > > <test xsi:type="xs:string">10</test> <!-- invalid --> > > 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. As far as I can see, <test xsi:type="xs:string">11</test> is perfectly valid! Saxon is currently reporting that xs:string and xs:integer are not validly derived from s2, which seems reasonable, but I can't see anything in the spec to justify it. Michael Kay http://www.saxonica.com/
Received on Friday, 31 December 2004 14:44:08 UTC