2174 2005-09-14 18:13:16 +0000 R-176: Question about mixed in derivation by extension 2009-04-21 19:21:34 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.0/1.1 both All All CLOSED LATER resolved P2 normal --- 1 sandygao cmsmcq www-xml-schema-comments oldest_to_newest 6171 0 sandygao 2005-09-14 18:13:16 +0000 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 6172 1 sandygao 2005-09-14 18:13:44 +0000 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 15204 2 sandygao 2007-05-25 13:47:02 +0000 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.