This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We have a proposal from Michael Kay on how to revise the story on composition. Intro: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2007Aug/0031.html Proposal: http://www.w3.org/XML/Group/2007/08/composition-2.pdf
We spent considerable time discussing this issue at the October, 2007 f2f in Redmond. Please see the meeting minutes for details: http://www.w3.org/XML/Group/2007/10/xml-schema-ftf-minutes
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.
If we decide to make a feature deprecated then I think we should also at the same time make it optional - that is, conforming processors should not be required to implement the feature. This provides users with a stronger incentive to stop using the feature than merely annoucing that future revisions of the spec might drop the feature, and it relieves new implementors from the burden of implementing something that users are being discouraged from using.
Well, I understand where MK is coming from on this, but on balance I think that making <redefine> in particular optional would be a mistake at this point. Granting that there is troubling variability in the way that it is implemented, I suspect that the simple cases interoperate reasonably well, and that at least some users will depend on that. In general, we have tried (at least I think we've tried) to make it the case that Schema 1.0 documents will work as well when given to Schema 1.1 processors as they do when given to Schema 1.0 processors. I'm lukewarm about the proposal to deprecate <redefine>, since we don't yet have implementation experience to prove that <override> will work well. I'm optimistic, but it's still early. Still, on balance, I can pretty easily live with deprecating as long as support is required. I don't think I can live with making it optional. So, if your argument carries the day on style grounds, and the group comes to agree that deprecate should imply optional, then I have to take a pretty strong stance that it can't be deprecated. If that argument does not carry the day, then I'm quite OK with making having support required in processors, but use deprecated for schema authors, as I believe is proposed in the current draft. Noah
The proposal mentioned in comment #2 was adopted by the XML Schema WG on today's call. Since the proposal at best ameliorates, but does not resolve, this issue I am not changing the status of the issue, only removing the keyword 'needsReview'.
The XML Schema WG considered this issue briefly at its teleconference of 13 June 2008. We observed that the WG does not have consensus on how to resolve the existing problems with the specification of schema composition and that periodic efforts to address composition issues over the last four years have uniformly met with failure as a result. The recent decision to define an xs:override element (bug 4767) and to deprecate xs:redefine (this bug, comment #2) have ameliorated but not really resolved the situation. So we have reluctantly agreed to close this issue for now with the hope that it can be reconsidered and resolved later. David, since you opened this issue on behalf of the XML Schema WG, it can be assumed that you are resigned to this disposition, if not content with it. But it would be convenient if you would signal that fact explicitly by closing the issue, or signal its opposite by reopening the issue. Thanks.