This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider the pathological test case particlesZ031 in the Microsoft part of the test suite <xs:complexType name="Type1"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="Field1" type="xs:string" /> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="Type2"> <xs:complexContent> <xs:extension base="Type1"> <xs:attribute name="Field2" type="xs:string" /> </xs:extension> </xs:complexContent> </xs:complexType> In Schema 1.0 the {content type} of Type2 is computed as follows: 1. The effective mixed is false 2. The effective content is empty 3.2.1 Therefore the {content type} is the {content type} of the base type definition, namely SIMPLE. Clearly this is perverse since the type specifies complexContent, but that's what the rules say. In 1.1 the effect is different (section 3.4.2.3.3). 1. The effective mixed is false 2. The effective content is empty 3. The explicit content is empty 4.2.1 applies, and takes us to 4.1.1, giving an explicit content type of (empty, absent, absent, absent) 5. The wildcard element is absent 6. The {content type} is the explicit content type, namely (empty, absent, absent, absent) So this time we have complex (empty) content, which means that by extending a type that allows string content we have created a type that allows no content at all. I think this case should simply be banned: a type with <complexContent> should not be allowed to extend a base type with variety=simple.
The WG discussed this issue during the ftf today. The status quo does in fact generate a result pretty much as described in the bug description, but the status quo also satisfies the demand that the example not be legal: the result generated by the mapping rules falls afoul of clause 1.4 of the Schema Component Constraint: Derivation Valid (Extension) and thus is not a conforming component. This is one of the cases covered by the note in section 3.4.1 which begins Not all combinations of {derivation method} and {content type} are compatible with all properties of the {base type definition}. We considered adding another note in the appropriate clause (4.2.1) of the mapping rule in 3.4.2.3.3, but (a) some were nervous about getting the exact wording of such a note right (is it invariably the case that if clause 4.2.1 fires, the result will violate a constraint on schemas? we thought so, briefly, but decided not), and (b) there are several other places where the mapping rules produce results which violate constraints on schemas; this is a consequence of making certain that the constraints on the XML representation of schemas are wherever possible testable against the XML in isolation. The end result is that we believe this issue should be classed as WORKSFORME. Michael, if you are willing to live with this resolution, please so indicate by closing the issue; if not, please prepare for a difficult argument within the WG.
*** Bug 6600 has been marked as a duplicate of this bug. ***