This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 4.2.5 contains in a Note the sentence "Source declarations not present in the target set of E cannot be overridden". A casual reader might interpret this as saying that it's an error to have an element declaration with name="N" as a child of xs:override if there is no element declaration in the "target set" (that is, the schema being overridden) with name "N". In fact, careful reading of the override transformation shows that this is not the case. So what exactly is it saying? It's presumably saying something about source declarations that actually exist but are not part of the target set. If those source declarations are in the wrong namespace, then it's a fact that you can't override them, because there is no mechanism to refer to them. Perhaps it's just pointing out that fact. But can there be source declarations in the right namespace that are not part of the target set? It seems there can: for example if A includes both B and C, and C overrides D, then a declaration in C/xs:override will conflict with a like-named declaration in B, rather than overriding it (xs:override, unlike xs:redefine, is not pervasive). It might be helpful to rephrase the sentence along the lines: "If there is no source declaration in the target set that matches a declaration E appearing as a child of xs:override, then E is processed exactly as if it appeared directly as a child of xs:schema. In consequence, E can conflict with like-named declarations contained in schema documents that are not part of the target set." It might also be helpful to point out that a complex type declaration cannot override a simple type declaration, or vice versa, even though they share the same symbol space. At the moment, I think you have to read the XSLT code to discover this.
Editorial changes needed listed in the resolution on the telcon 2010-05-14.
I'm feeling very slow. The bug description suggests adding the sentence If there is no source declaration in the target set that matches a declaration E appearing as a child of xs:override, then E is processed exactly as if it appeared directly as a child of xs:schema. but I don't see anything in the spec or the transformation that has this effect. The minutes of 14 May 2010 referred to in comment 2 have a different account of what happens to E: add a note saying declarations are ignored if there's nothing for them to override. That is more in accordance with my understanding. A second point is that the minutes also say you may need to apply the transformation more than once. I am finding it hard to draft a note to that effect since I don't know what is meant. (This is a problem with delaying drafting until nine months after the first-pass decision was made.) If what is meant is "The override transformation may have to be applied more than once to the same schema document and override element", then I do not now understand why this should be so. If what is meant is "If the schema document produced by the override transformation itself contains override elements, the transformation will have to be performed on the schema documents pointed to by those elements" then I am not sure why this needs saying, or where to say it. (It seems to me to follow pretty clearly from the general description of how override elements are handled.) On the theory that what was meant was the second gloss, and on the theory that the answer to my question is "It may follow clearly, but it's not obvious at first glance; a note would help", I'll draft a note, which will be included in a wording proposal to go to the WG in due time.
A wording proposal intended to resolve this issue is now on the server at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b9661.html (member-only link)
If my recollection is correct, when I wrote this bug entry I was under the impression that the WG's intent was that if you write <xs:override><xs:element name="A"/></xs:override> and there is no element named A to be overridden then the effect should be the same as if <xs:element name="A"/> had been written outside the <xs:override>. When the WG looked at the bug it decided this was not the intent, and the behaviour should be as if the <xs:override> did not include the <xs:element name="A"/> element.
The proposal mentioned in comment 3 has been adopted and the necessary changes have been integrated into the status-quo documents at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.diff-wd.html http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.diff-1.0.html (member-only links) Accordingly, I'm marking this issue as resolved. Michael, if you would verify the fix and close or reopen the issue accordingly? Thank you.