16786 2012-04-18 18:05:18 +0000 S4S does not allow openContent without group in complex type restriction 2015-05-23 18:59:56 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only PC Windows NT RESOLVED FIXED resolved P2 normal --- 1 pwalmsley David_E3 cmsmcq mike www-xml-schema-comments oldest_to_newest 66809 0 pwalmsley 2012-04-18 18:05:18 +0000 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.) 66898 1 cmsmcq 2012-04-20 16:34:32 +0000 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. 66899 2 David_E3 2012-04-20 16:46:41 +0000 WG decided that the group following openContent should be optional. Gives a work-around and a fix. 66900 3 mike 2012-04-20 16:49:15 +0000 (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. 66908 4 mike 2012-04-20 20:30:39 +0000 (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. 66926 5 mike 2012-04-21 22:41:24 +0000 > 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. 76819 6 cmsmcq 2012-10-20 20:58:51 +0000 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.) 76840 7 pwalmsley 2012-10-21 14:52:08 +0000 Looks good to me. Thanks! 78716 8 cmsmcq 2012-11-23 17:24:48 +0000 Since PW has already reviewed and agreed with the change, I'm closing this issue. 120456 9 pwalmsley 2015-05-23 18:59:56 +0000 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