This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In June 2003, the XML Schema WG briefly discussed cases like the following: XSD1: <schema ...> <complexType name="CT"> ... </schema> XSD2: <schema ...> <redefine schemaLocation="XSD1"> <!-- CT in XSD2 is vacuous restriction of CT in XSD1 *--> <complexType name="CT"> <restriction base="CT"/> </complexType> </redefine> </schema> XSD3: <schema ...> <import schemaLocation="XSD1"/> <import schemaLocation="XSD2"/> </schema> Several questions arise: 1. is this legal or not, in XML Schema 1.0? 2. regardless of the answer to (1), SHOULD this be legal in XML Schema? One position one could take is that since the CT of XSD1 and the CT of XSD2 are as similar as one can make them (same name, same extension), the double import really should be legal. Another possible position is that if one wanted them to be identical one would not have redefined CD in XSD2 -- just as vacuous restrictions can be used to block certain substitutions by imposing a certain structure on the type hierarchy, so the vacuous restriction here should be allowed, and should not be treated differently from a non-vacuous restriction. When this came up in June, some WG members offered an analysis of this case which led them to conclude that the example is not legal; I never understood the details. Can anyone expound? Depending on what the WG decides to do, this topic might turn into an error report on 1.0 or a requirement for 1.1, or a no-action-needed. See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JulSep/0062.html
This issue involves 2 questions: 1. Do vacuous redefinitions produce the same component as the original? I think the answer is "no" and the spec is very clear about this. "CT" in XSD1 (call it CT-1) has a base type (the one named in is "base" attribute or "anyType"). "CT" in XSD2 (call it CT-2) has CT-1 as its base type. This makes CT-2 a different type from CT-1. Conclusion from this: how redefinition works is not impacted by whether it's vacuous or not. 2. Is it leagal to import both the orignal schema document and a redefintion of it? This is closely related to (and depends on) the question of what "redefinition is pervasive" means (see bug 2330). What's interesting about "import" is that the spec allows processors to "ignore imports for the same namespace but the first one". So a processor can ignore the XSD2 import and only use XSD1. Suggestion: open a new issue to track the "pervasive redefinition" issue; mark this one (and bug 2330 and possible bug 2577) as depending on that new issue, because all those 3 issues are just different symptoms of the same fundamental question.
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.