- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Fri, 25 Feb 2011 08:59:00 -0700
- To: www-xml-schema-comments@w3.org
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
On Feb 25, 2011, at 6:03 AM, bugzilla@jessica.w3.org wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12184 > > Summary: Circularity in xs:override > 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: David_E3@VERIFONE.com > ReportedBy: mike@saxonica.com > QAContact: www-xml-schema-comments@w3.org > CC: cmsmcq@blackmesatech.com > > > I believe there are problems in the spec in explaining what happens when two > schema documents each contain xs:override elements referring to the other (or > more generically, with any cycles in the xs:override graph, including as a > special case a document that attempts to override itself). Should one take the filing of this bug report as a signal that you do not find the analysis in http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2011Feb/0014.html persuasive? > Consider test case over023. This contains two documents, which I shall call P > (actually over023.xsd) and Q (actually over023a.xsd). > ... > > To determine schema(P') we again need to evaluate override(Q, E), and since > neither Q nor E have changed, this will produce a result identical to Q'. So > the process as described never terminates. I'm not sure what "the process as described" means here; the spec really should not be describing a process but specifying a result. But if the process you mean is a stack-based approach of handling each override and/or include at the moment they are encountered while processing a schema document, without cycle checking, then yes, the process does not terminate. For comparison, that is also precisely the situation with the analogous process applied to cycles of inclusions: in trying to calculate the meaning of some expression schema(D) you find yourself needing to calculate, possibly among other things, the meaning of the expression schema(D). > > It's possible that this paragraph was intended to provide a termination > condition: "If applying the override transformation specified in Transformation > for xs:override (§F.2) to D and E results in a schema document equivalent to D > (e.g. when none of the [children] of D, or of any <redefine> and <override> > elements in D match any of the [children] of E, except for the [children] of E > themselves), then the effect is the same as for a cyclic set of <include> > references". > > However, it's far from clear what is meant by saying "the effect is the same". Yes. Unfortunately, as you may recall from the discussions when the override proposal was adopted, that is partly by design: the WG turned out not to have any agreement about what the 1.0 rules for include actually mean in the presence of cycles, or how to define 'cycle' in such cases. The spec encourages schema authors to avoid cycles "to forestall the necessity of establishing identity component by component". If I understand the situation correctly, different members of the WG have two different interpretations of those words. One group reasons that if avoiding cyclic inclusions forestalls the necessity of establishing identity component by component, then failing to avoid cycles must impose the task of establishing identity component by component (through some kind of deep-equality checking, presumably, which must be straightforward and obvious since the spec does not define it). They infer, then, that these words of the spec implicitly impose on implementations the task of checking source declarations individually to see whether the component they describe is already present in the schema or not. The other group says no, that's not the case, because that's not what the words mean. I cannot record here what this group thinks those words do mean; they have not, to my recollection, ever endeavored to explain that to the rest of the WG. This may be one of those cases beloved of some in the WG in which they say, in effect, that these words in the specification are inconvenient and therefore mean nothing and may simply be ignored as empty filler. When the WG discussed the wording for the override proposal, one WG member asked "does this proposal impose a requirement for deep equality checking?" After discussion, the conclusion of the WG was "if the requirement of deep equality checking is imposed by the rest of the spec, this proposal does not remove it. If it is not imposed by the rest of the spec, this proposal does not add it. The rules of the spec regarding deep equality checking are not affected by this proposal." Since the WG does not have consensus on what those rules are, though, all we were able to say in the description of override was that the effect is the same as the effect of cyclic includes. In other words, the WG's failure to address the issue of component identity and to clear up our schema composition story continues to bear fruit. The WG did clean up one question left unspecified by 1.0: we agreed that a fixpoint semantics can be assigned to cyclic inclusions. Within the context of the stack-based processing you describe in your mail, that amounts to saying "if you are calculating the meaning of some expression E (say, "schema(D)" or "schema(override(E,D))") and the same term reappears as a subterm of a union expression, the subterm may be eliminated on the grounds that the value of E is necessarily present as a subset of the value of E. > > Looking beyond the mechanics of the detailed rules, it's hard to see what they > are trying to achieve. What is the use case for permitting cyclic xs:overrides? I don't know a use case. > Given the purpose of xs:override, it feels like a logical error, and I can't > see why we don't treat it as such. I think the main argument against treating it as an error is that the meaning of override is given in terms of the meaning of inclusions. If cyclic inclusions are legal, and overrides are defined in terms of inclusion, and cyclic overrides reduce (as you have illustrated) to cyclic inclusions, what logical grounds exist for banning cyclic overrides? It would be consistent from a logical and from a design pov if we banned cycles both in inclusions and in overrides. But I expect pushback from implementors whose software currently accepts cyclic inclusions. Implementors whose software currently does not accept cyclic inclusions are less well represented in the WG. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Received on Friday, 25 February 2011 15:59:30 UTC