This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The Schema for Schemas does not allow a complex content restriction where an openContent is specified without a group/all/choice/sequence. It is legal to restrict away the entire content model (if everything is optional), so why should you not be able to specify this: <xs:complexType name="ProductType"> <xs:openContent> <xs:any namespace="##any"/> </xs:openContent> <xs:sequence> <xs:element name="child1" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="RestrictedProductType"> <xs:complexContent> <xs:restriction base="ProductType"> <xs:openContent> <xs:any namespace="##other"/> </xs:openContent> </xs:restriction> </xs:complexContent> </xs:complexType> A corner case, to be sure, but it seems like it should be a legal restriction, and the Schema for Schemas considers this invalid. (Incidentally the Schema for Schemas differs slightly from the XML Representation Summary in 3.4.2.3 in this regard.)
Not verified, but I think it should work if you write <xs:complexType name="RestrictedProductType"> <xs:complexContent> <xs:restriction base="ProductType"> <xs:openContent> <xs:any namespace="##other"/> </xs:openContent> <xs:sequence/> </xs:restriction> </xs:complexContent> </xs:complexType> The discrepancy between the syntax display and the schema for schema documents, on the other hand, needs to be resolved to make them consistent. I'm not sure which to change.
WG decided that the group following openContent should be optional. Gives a work-around and a fix.
(Note Saxon 9.4 accepts this example, but its parsing in this area uses a state machine that was originally constructed automatically from the S4S. Need to investigate how this happened). The example in the bug has been added to the test suite as saxonData/Complex/complex017.
(In reply to comment #3) > (Note Saxon 9.4 accepts this example, but its parsing in this area uses a state > machine that was originally constructed automatically from the S4S. Need to > investigate how this happened). > I don't know whether the archaeology is useful, but I have a copy of a compiled version of the S4S created on 2007-03-05 in which it is clear that the typeDefParticle in the content model at that time had a minOccurs of zero. I don't have the corresponding source, but another compiled version from 2007-08-30 appears to make typeDefParticle mandatory. The current Saxon source appears to be built from the earlier version: it is characterized by the fact that the transition corresponding to openContent is to a state labelled as a final state. I've used the same code to regenerate the FSM from the current S4S, and as one would expect, it requires content after the openContent element. So I would suggest that we made a change to the S4S at some time during mid 2007 which introduced a bug.
> So I would suggest that we made a change to the S4S at some time during mid > 2007 which introduced a bug. I should perhaps have added: * the working draft of 2007-08-30 is essentially the same as the final version * the previous published working draft of 2006-08-31 did not include openContent * therefore it would appear that the version I used to generate my grammar was an unpublished draft; I've done some searching through the mail archives but haven't been able to locate such a draft.
A diffed version of the spec showing a draft erratum for this issue is now on the server at https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.errata-2012.html (member-accessible link) The WG did not want to review this text, so I'm marking this bug as 'needs publication'. [Note: I have not invested any time in figuring out what went wrong here. So if this error is the tip of an iceberg, we have avoided taking this opportunity to discover the fact.] Priscilla, if you could, please review the resolution of the issue and let us know whether you have any objections to it. If we don't hear from you in the next two weeks or so, we'll assume you are happy with the changes. (If you don't currently have member access, let us know so I can send you a copy of the diffed spec.)
Looks good to me. Thanks!
Since PW has already reviewed and agreed with the change, I'm closing this issue.
Changing status from CLOSED back to RESOLVED because otherwise this bug does not appear in the search linked to from the Errata page at http://www.w3.org/XML/XMLSchema/v1.1/1e/errata.html