Bug 14416 - Non-normative description of xs:override transformation
Non-normative description of xs:override transformation
Status: CLOSED FIXED
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1
1.1 only
PC All
: P2 minor
: ---
Assigned To: David Ezell
XML Schema comments list
: resolved
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-10 08:46 UTC by Michael Kay
Modified: 2012-01-06 23:43 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kay 2011-10-10 08:46:11 UTC
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.]
Comment 1 Michael Kay 2011-10-12 16:16:04 UTC
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.
Comment 2 David Ezell 2011-10-21 15:22:11 UTC
WG agrees in principal, but is marking this item needsDrafting so MSM has an opportunity to recheck.
Comment 3 C. M. Sperberg-McQueen 2011-12-27 21:59:17 UTC
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.
Comment 4 C. M. Sperberg-McQueen 2011-12-27 22:48:21 UTC
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.
Comment 5 C. M. Sperberg-McQueen 2011-12-27 23:39:13 UTC
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
Comment 6 Michael Kay 2011-12-29 11:35:47 UTC
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.
Comment 7 Michael Kay 2011-12-29 11:46:32 UTC
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".
Comment 8 C. M. Sperberg-McQueen 2011-12-29 15:25:38 UTC
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.
Comment 9 C. M. Sperberg-McQueen 2012-01-06 23:32:35 UTC
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.