This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If among the set of schema documents consulted in constructing a schema the same schema document is referred to both with an include (or it is one of the schema documents specified by the user as the basis for the schema to be constructed), and also with a redefine reference, what happens? One view is that the spec says clearly that an including reference results in a specific schema, whose components are included in the ultimate result schema, and that a redefining reference results in a different set of components, which will conflict with the first set and cause an error. Another view is that redefinition is said to have ubiquitous effect, so that the redefinition of components should also affect components directly included in the schema. This issue was discussed in Redmond in August 2004: http://www.w3.org/XML/Group/2004/08/xml-schema-ftf-minutes#id0x08cdd2c0 XSD 1.1 must be clear on what effect this has (this is part of requirement RQ-151 to clarify schema composition), and a clarification or erratum should be issued on XSD 1.0.
FWIW, I strongly feel that the pervasive effect of redefine should trump any implications to the contrary that may be read into the text regarding include. If the effect of redefine is not pervasive, then we have the potential of two or more different versions of the same named definition or declaration being used in the same schema, and I think that's a very bad idea. ref="..." and similar constructs should unambiguously resolve to the "most redefined" version of a component, regardless of where the reference appears. The only exception is that the redefinitions themselves can have access to their similarly named antecedents, e.g. as base types. Noah
Reviewing the open bugs, I find Noah's comment of last December, which puzzles me in one respect: what gives rise to the belief that either possible answer to this question has "the potential of two or more different versions of the same named definition or declaration being used in the same schema"? That's a very persuasive argument against the position that the effect of redefine should not be pervasive and that the resulting schema should be legal. If anyone had taken such a position, your argument would have, I hope, good effect in persuading them of their error. But it doesn't seem to bear on the issue that is actually before us, as that is outlined in the description of the issue.
Michael asks: > what gives rise to the belief that either > possible answer to this question has "the > potential of two or more different versions > of the same named definition or declaration > being used in the same schema"? The original comment offers as one alternative: > and that a redefining reference results > in a different set of components, which will > conflict with the first set and cause an error. Maybe we're at cross purposes because this does say that an error will be caused, so in that sense there's no schema. Othewise, this clearly says that there will be conflicting versions of what I infer to be global components in the same symbol space with the same name. It very clearly contrasts that with: > Another view is that redefinition is said > to have ubiquitous effect So, in only one of the alternatives is the effect of redefine ubiquitious. The alternative, as noted above, leads to the view that a schema document specifically including some particular document will see the "unredefined" versions of the components declared therein, even if elsewhere a redefine has been done that would override them. As I stated in my original comment, I think the statement that redefine is pervasive should trump any inference to the contrary that might be drawn from what's stated in relation to <xsd:include> I'm not specifically saying that's my reading of <xsd:include>, but apparently the commentator found an ambiguity. Noah
On its telcon today, the Working Group discussed this and other issues related to schema composition and concluded (not without some pangs of regret) that for scheduling reasons it is not feasible for us to resolve them before we go to Last Call. The WG continues to believe that this issue is important and should be resolved; our decision to close the issue for now reflects the fact that we have not been able to reach consensus on how to resolve the problems related to composition, coupled with the observation that for the most part, users are able to avoid the problems by avoiding problematic constructs in their schema documents. The cost of delaying XSDL 1.1 for these issues is thus high, while the practical benefit for users is not as high as it might be. The Working Group continues to hope that this issue can be resolved at some point in the future. Accordingly I am closing this issue with a disposition of LATER.
A wording proposal intended to resolve this issue in part is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b2224.html (memger-only link). The resolution is only partial, because the proposal does not actually repair any problems directly; it only deprecates xs:redefine in order to warn schema authors away from it and make it possible to remove the feature at some future date.