5932 2008-08-06 13:31:06 +0000 Open content with empty content models 2008-08-06 13:35:36 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only PC Windows NT RESOLVED INVALID P2 normal --- 1 mike cmsmcq www-xml-schema-comments oldest_to_newest 21447 0 mike 2008-08-06 13:31:06 +0000 Consider: <xs:complexType name="e"> <xs:openContent> <xs:any namespace="http://wild.com/"/> </xs:openContent> <xs:sequence/> </xs:complexType> Working through the rules in 3.4.2.3.3: 1. The effective mixed is false 2. The explicit content is empty 3. The effective content is empty 4. The explicit content type is: (variety=empty, particle=absent, open-content=absent, simple-type-definition=absent) 5. the wildcard-element is the openContent element 6. Therefore the {content type} property is (variety=empty, particle=<sequence/>, open-content=(<xs:any/>, interleave), simple-type-definition=absent) So the rules seem to go to some lengths to ensure that the {content type} includes the open content. This would be even more true if the open content were derived from a <defaultOpenContent> with appliesToEmpty=true. But now look at the validation rules in 3.4.4.2. Rule 1 is: 1.1 If T.{content type}.{variety} = empty, then E has no character or element information item [children]. That is, it doesn't make any difference what {content type}.{open content} says, the element is only valid if there are no children. Only if {variety} is mixed or element-only do we invoke Element Sequence Locally Valid (Complex Content) (§3.4.4.3), which is where {open content} comes into play. I find it hard to believe this was intended, especially given the attribute appliesToEmpty. Also it seems we have carefully constructed a complexType schema component that violates the constraint in 3.4.6.1: 5 If {content type}.{open content} is ·non-absent·, then {content type}.{variety} is either element-only or mixed. I'm not sure what the right fix is. It might be to make variety=element-only in this case. But this would also have effects on deriving types by extension, and I haven't begun to study in detail what happens when types with open content are extended. (Incidentally, another consequence of the current rules is that a defaultOpenContent applies to <xs:complexType name="e" mixed="true"> <xs:sequence/> </xs:complexType> whether or not it specifies appliesToEmpty="true". I don't know if this was the intention. But it does no harm.) 21448 1 mike 2008-08-06 13:35:36 +0000 Ah, shucks. All that work and I took a wrong turning in rule 6.3 of 3.4.2.3.3 which does indeed change the {variety} to element-only. Forget it.