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 following schema fragment: <xs:complexType name="mixed" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="test:a"/> <xs:element ref="test:b"/> <xs:choice> <xs:complexType> <xs:element name="root"> <xs:complexType> <xs:complexContent> <xs:extension base="test:mixed"> <xs:attribute name="id" type="xs:ID"/> <xs:extension> <xs:complexContent> <xs:complexType> <xs:element> Is the following instance valid? (i.e. is root allowed to have mixed content?) <root xmlns="http://example.com/test"> ccc<a>aaa<b>bbb<b>aaa<a>ccc<b>bbb<a>aaa<a>bbb<b>ccc <root> Henry's response: Yes. Note, however, that this "redundancy" can only be avoided when the extending definition is empty -- if any substantive element content is added, then the result is specified by the REC to take its 'mixed' from the extending definition. But the REC also rules out extending mixed with element-only or vice-versa, so there's no point. This isn't a big deal, but it should probably be fixed, by - specifiying that in complexContent extension, the mixed _always_ comes from the base; - ruling out conflicting 'mixed' on <complexType> or <complexContent> when deriving by extension. See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0087.html
Discussed at the 2003-11-14 telecon. Sandy Gao to study the relevant sections and report back to the WG Sandy's research: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Dec/0029.html
Discussed at 2007-05-18 telecon. The issue may be solvable, but the benefit doesn't seem to justify the amount of spec changes. The WG decided to marking this issue as LATER, meaning it *may* be dealt with in a future schema release after 1.1.