This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A consequence of the way xs:override is specified is that document-level defaults (elementFormDefault, attributeFormDefault, blockDefault, finalDefault, defaultAttributes, xpathDefaultNamespace, defaultOpenContent) in the overriding document have no effect on declarations nested within an xs:override element in that document; instead, the effective values are those that apply in the overridden document. This behaviour is different from xs:redefine. The purpose of this bug report is (a) to check that this was indeed the intention of the WG (I don't recall it being discussed, and it doesn't seem intuitively correct) (b) to ask whether it would be appropriate to add Notes to warn the user of surprises in this area. It's currently very easy to misread statements such as that in 3.3.2 ("Control over whether element information items ·validated· by a local declaration must be similarly qualified or not is provided by the form [attribute], whose default is provided by the elementFormDefault [attribute] on the enclosing <schema>, via its determination of {target namespace}.") without realizing that the term "enclosing <schema>" is to be understood as applying to the post-transformation schema document.
WG discussed and decided not to change the transform, but to clarify the text to make the effects apparent. Also clarify the effects of namespace bindings.
I propose to resolve this by inserting the following note in the sequence of notes following Schema Representation Constraint: Override Constraints and Semantics, immediately following the note reading Note: It is Dold′ and not Dold, which is required to correspond to a conforming schema. In particular, it is not an error for Dold to fail to satisfy all of the constraints governing schema documents, while it is an error if Dold′ fails to satisfy them. The proposed addition: Note: The effect of override pre-processing is that any declarations and definitions contained within an <override> will be substituted for matching declarations and definitions within the target set; the resulting schema documents will then be processed normally, as described in the relevant portions of this specification. This has the effect that the rules for document-level defaults (elementFormDefault, attributeFormDefault, blockDefault, finalDefault, and so on) are applied not in the context of the document containing the <override> (Dnew) but in the context of the document containing the original overridden declaration or definition (Dold). Unexpected results may be minimized if the children of an <override> are made independent of the document-level defaults by explicitly specifying the desired values for the properties in question. For the record, I note that I think it would be technically feasible (if a little fiddly to specify and get right) to supply explicit values automatically for all the document-level defaults, before processing the included element. That's not the direction taken in this change proposal because it's not the direction taken in the WG's phase-1 agreement on technical direction. It can in any case also be done by a utility stylesheet anyone could provide for use by schema authors who dislike the default behavior; it does not need to be written into the XSD spec and the task does not need to be performed by the schema processor.
Adopted as proposed on telcon 2011-02-04
The changes mentioned in comment 2 have been integrated into the status-quo document, so I'm marking this issue as resolved. Michael, if you would close or reopen as needed? Thanks.