This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Two additional rules could usefully be added to the non-normative description of the xs:override transformation given in F.2, to make it more closely reflect the normative transformation: 0 [before the "for each element information item E2"]. The attributes of D2' (for example, targetNamespace and defaultAttributes) are copies of the attributes of D2. 5. [part of the "for each..."] If E2 is any other element type (for example, defaultOpenContent), then D2′ has an element identical to E2 in the same place as where E2 is in D2. [I would also quibble with the use of "identical" in these rules - it appears to consider two elements identical even though their [parent] properties differ - but it's non-normative, and no readers will be confused, so I guess this doesn't really matter.]
There are further problems with this non-normative description of the transformation: (a) "For each element information item E2 in the [children] of D2's <schema>, <redefine>, or <override> information item". Should perhaps read "For each element information item E2 that is a child of D2's <schema> element or a child of a <redefine> element appearing as a child of that <schema> element". I don't think the rule applies to children of <override> because they are handled in the subclauses of clause 4. (b) In the Note: "Note: Informally, the rule just given has the effect that O2 contains (a) all the [children] of O1, as well as (b) all of the [children] of E2 which are not overridden by some child of O1. The elements corresponding to [children] of E2 come first, followed by the [children] of O1 which matched nothing in E2.". Here E2 is incorrect. Perhaps the Note would be better written: Note: informally, the rule just given has the effect that O2 contains copies of all the declarations and definitions appearing as children of the <override> element O1, together with copies of all the declarations and definitions in D2 that are not overridden by a declaration or definition within O1. The declarations from D2 come first, followed by the declarations from O1 that matched nothing in D2.
WG agrees in principal, but is marking this item needsDrafting so MSM has an opportunity to recheck.
Re-reading the transformation, I begin to wonder whether the treatment of xsd:redefine is correct. Consider the following situation: - schema document v1 declares a type T but does not specify it further. So it defaults to being a vacuous restriction of xsd:anyType. - schema document v2 includes a redefine of v1, with a child declaring type T as a complex type with simple content consisting of xsd:date - schema document v3 includes an override of v2, with a child declaring type T as a complex type with simple content consisting of xsd:gYear Schema documents illustrating this configuration are on the W3C server at http://www.w3.org/XML/2008/xsdl-exx/b14416-base.xsd http://www.w3.org/XML/2008/xsdl-exx/b14416-v2.xsd http://www.w3.org/XML/2008/xsdl-exx/b14416-v3.xsd I believe that what the WG wanted in this situation was that the override transformation, performed with the override element in v3 as O1 and with schema document v2 as D2, should insert v3's version of the declaration of type T into the xsd:redefine element. I believe the transform as currently written fails to do this, because any redefine will be a child of xsd:schema and thus match two templates. One template with a match pattern of schema-element(xs:schema) | schema-element(xs:redefine) This template copies the element and its attributes and then calls xsl:apply-templates on the children. Its default priority, if I understand XSLT 2.0 correctly, is 0.25. The other template has a match pattern of schema-element(xs:schema)/* | schema-element(xs:redefine)/* | schema-element(xs:override)/* It performs a deep copy of either the current element or its replacement in the override element, and does not call apply-templates on the children. Its explicit priority is 3. In the example, the result is that the redefine element in the D2' produced by the override transformation (as we have defined it in the spec) is a deep copy of the redefine in v2, instead of having its children overridden by matching elements in the override of v3 One possible repair is to assign a priority of 5 to the template which currently has no explicit priority. I don't think that's likely to break anything.
With respect to the second point made in comment 1, I am not sure I understand or agree. The phrase "The rule just given" refers to rule 4, governing the handling of xsd:override elements in the overridden schema document D2, and it seems to me to be correct. The passage is not as easy to follow as it ought to be in part because there are too many different things we need to refer to, and thus too many different variable names: D1, D2, D2', O1, E2, O2. Perhaps O2 should be renamed E2', to make the similarity more explicit: D2 : D2' = E2 : E2' D2' is the override of D2 by O1, and E2' (O2 in the current draft) is the override of E2 by O1. The override element included in D2' (O2, perhaps to be renamed E2') contains copies of all the children in O1, whether they matched anything in E2 or not, and it also contains copies of all the children of E2 which weren't overridden. It doesn't contain elements for the other declarations of D2.
Proposal (member-accessible) at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b14416.html It adopts the changes suggested in the original bug report, replaces mentions of identity with mentions of copying, adopts the first change in comment 1, attempts to address the second change in comment 1 by changing the variable name O2 to E2' (to try to make the parallel between E2 / E2' and D2 / D2' more evident), and sets a priority of 5 for the hitherto default-priority template for xsd:schema and xsd:redefine. WG action requested
Re comment #3: I agree; the analysis of the problem and the proposed resolution are correct. Re the second point in comment #1 and the response in comment #4, I think the problem is that I did not read "the rule just given" as referring to clause 4 of the paragraph starting 'For each element information item E2...', but rather to the whole paragraph.
There appear to be a couple of typos in the proposed text. (a) The replacement paragraph starts "For each element information item E2 in the [children] any <schema> or <redefine> element information item within D2, the appropriate case among the following is true" should "of" appear after "[children]"? (b) In rule 5, spurious apostrophe in "correspond's".
The typos noted in comment 7 have been corrected (thank you!) and the proposal regenerated. One good consequence of adding item 5 in the numbered list is that it may help make clearer that the note after clause 4 is a note on clause 4 and not the whole process. But perhaps (it occurs to me now) "the rule just given" should be replaced with "clause 4" to make the reference more explicit.
The proposal mentioned in comment 5 was approved (as amended) at the XML Schema WG call today and the changes have been integrated into the status-quo documents. So I'm marking this issue resolved. Michael, as originator of the issue it falls to you to close the bug formally to indicate your satisfaction with the WG's resolution of the issue. Thanks.