This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Dear members of the XSD 1.1 working group In the text of recommendation 1.1, the rules number : - 1.1 and 1.2 of section 4.2.3 - 2.1 and 2.2 of section 4.2.4 have been changed so that an included or redefined <schema> could now be not a conforming schema. By doing this, it appears that one same root element "xs:schema" could introduce both a simple "well formed XML document" and a conforming XML Schema. I'm afraid that it is : 1) introducing confusions about what is a schema and what is not. 2) transforming the original pure XML Schema logic into the traditional DTD approach where physical chunking could led to bad management of elements definitions. The original strict logic of XSD has helped some working groups to clarify the design of complex models, to rationalize the writing of those models and the organization of the sets of elements and attributes. You will find enclosed the presentation I did about the problem of physical chunking to the ASD/S1000D/EPWG (the Electronic Publication Working Group of the Association of the Aerospace and Defence Industry) at Clearwater (Florida) in 2005. If a physical chunking is necessary for the migration of some past models based on DTDs, then I suggest that a clear new element is used instead of <xs:schema> and clear new statements are used instead of <xs:include/import/redefine>. At least to avoid confusion between the past and this new approach and help the designers to choose between one or the other approach. About the new <xs:override> mechanism, I would also like to highlight the fact that the need for such a feature could be the result of some past DTD mechanisms (of course the SYSTEM ENTITY one). In terms of data modeling, I consider that it does not help at designing pure XML "hierarchical" models. Those changes in the specification dramatically change the phylosophy and logic of XML Schema and one question arises : Should XML Schema mimics the DTDS ? Do we really need a 100% functional compatibility between DTDs, XML Schema and Relax NG ? and also Schematron ? Yours sincerely and I apologize if you condiser that my vision and comment are stupid. Jean-Jacques Thomasson French translator of XML Schema Part 0 and 1. French translator of O'Reilly book "XML Schema". Author of "Schémas XML" (2002) and "Modélisation XML" (2006) at Eyrolles publishing house.
Created attachment 824 [details] Clearwater presentation about XML Schema logic and chunking of DTDs
>an included or redefined <schema> could now be not a conforming schema. It's not clear to me how you come to this conclusion. Looking only at include for the moment (4.2.3), rule 2 identifies four possibilities. For the first two (where the includer and includee have the same target namespace), rule 3.1.1 says that the included document must "correspond to a conforming schema". For the third case, (chameleon include), rule 3.2.1 says that the included document must "correspond to a conforming schema" after converting it to the target namespace. The fourth case is where the schemaLocation URI fails to resolve, and presumably this is not your concern. What has changed, I think, is that for the chameleon case the rule about the included document corresponding to a conforming schema is now applied AFTER moving it into the namespace of the caller. I don't remember the detailed logic here, but we now describe rather more clearly how this transformation is effected, and I guess we found some edge cases where the transformation converts a document that corresponds to a valid schema into one that doesn't, or vice versa. (I can more easily imagine cases where the transformation makes it invalid, for example if components after moving into the target namespace now clash with existing components that were already in that namespace.) Incidentally, we're still rather vague about what exactly it means for a schema document to "correspond to" a schema, particularly when it comes to things like circular includes and redefines. We made a serious effort to tackle this but eventually decided it was too much work for 1.1. But it hasn't got any worse.
The description of the issue is correct to note that in section 4.2.3 (on include), the phrase "which in turn corresponds to a valid schema" has been deleted from clauses 1.1 and 1.2 of Schema Representation Constraint: Inclusion Constraints and Semantics. And similarly in section 4.2.4 Schema Representation Constraint: Redefinition Constraints and Semantics has dropped that phrase from clauses 2.1 and 2.2. But comment 2 is correct to observe that this is not a relaxation but a clarification of the constraint intended. In both sections, the constraint is moved and reformulated rather than deleted: in 4.2.3 it now appears in clauses 3.1.1 and 3.2.1; in 4.2.4 it is clauses 4.1.1 and 4.2.1. Moving the formulation allows the spec to make clear that in the case of chameleon include the constraint applies to the result not to the input of chameleon-include processing. (Apart from the greater clarity, this is necessary because chameleon include processing is defined in XSD 1.1 as applying at the schema-document level, not at the schema component level. Attempts to define it at the component level were unsuccessful.) The constraint has also been rephrased slightly; instead of correspondence to a "valid schema" the spec now speaks of correspondence to a "conforming schema". The term "valid schema" is not defined anywhere in either XSD 1.0 or XSD 1.1; in both versions of the spec, "validity" is the conformance of a *document* to the specifications of a document grammar (e.g. a DTD or an XSD schema). I hope this helps, and reassures you that the changes you identify in the text of XSD 1.1 do not represent a dramatic change of philosophy on the part of the spec.
On 2010-02-19 the WG had a telcon at which this issue was discussed. The WG deemed that comment #3 from Michael Sperberg-McQueen was accurate, and gives the appropriate rational for why the spec is as it is. For this reason, the WG resolved to close this issue as Invalid, with sincere thanks to the commenter for reading the spec carefully and taking the time to comment. We hope this resolution is satisfactory.
The WG reported this bug as INVALID on 2010-03-05. We are closing this bug as requiring no futher work. If there are issues remaining, you can reopen this bug and enter a comment to indicate the problem. Thanks very much for the feedback.