[Bug 5932] New: Open content with empty content models

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5932

           Summary: Open content with empty content models
           Product: XML Schema
           Version: 1.1 only
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: cmsmcq@w3.org
        ReportedBy: mike@saxonica.com
         QAContact: www-xml-schema-comments@w3.org


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.)


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 6 August 2008 13:31:41 UTC