This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Regarding _XML_Schema_Part_1:_Structures_Second_Edition at http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/: In section 3.4.1, the spec says: {prohibited substitutions} determine whether an element declaration appearing in a ·content model· is prevented from additionally ·validating· element items with an xsi:type (§2.6.1) attribute that identifies a complex type definition derived by extension or restriction from this definition ... The wording doesn't specify anything about the relationship between the element declaration and the given type definition ("'this' definition"). It appears that the intent was to refer to any element declaration whose type definition is the given definition. If that's the case, the wording should say that more explicitly. (If the intent is something else, then obviously the wording still needs to be clarified.) Section 3.4.1 continues: ... or element items in a substitution group whose type definition is similarly derived. That wording is also erroneous and/or ambiguous: 1. Element information items aren't actually in (aren't members of) substitution groups; only element _declarations_ are. Therefore, it seems that the intent was to refer to element information items (potentially) validated against element declarations (potentially) in substitution groups. Whatever the intent, the wording should be clarified (so a detailed analysis since as this isn't required to extract the intent). 2. Does "whose" refer: - to the substitution group's head or - to other element declarations that are (potential) members of the substitution group? That is, was the intent to talk about: - the derivation _to_ the type definition of the element declaration that is the head of the substitution group (from the given type definition) or - the derivation _from_ the given type definition used as the substitution group's head's type to member declarations' type definitions?
Thank you very much; good catch. We will try to fix this problem. The editors have thus far developed two proposed changes to the paragraph in question; the originator of the issue (Daniel Barclay) or others may have views on which to take, which would be helpful. One relatively simple fix is to delete two phrases and insert two others, so that instead of reading {prohibited substitutions} determine whether an element declaration appearing in a content model is prevented from additionally validating element items with an xsi:type (§2.6.1) attribute that identifies a complex type definition derived by extension or restriction from this definition, or element items in a ·substitution group· whose type definition is similarly derived: If {prohibited substitutions} is empty, then all such substitutions are allowed, otherwise, the derivation method(s) it names are disallowed. it reads {prohibited substitutions} determine whether an element declaration ED having this complex type definition as its {type definition} is prevented from additionally validating element items with an xsi:type (§2.6.1) attribute that identifies a complex type definition derived by extension or restriction from this definition, or element items whose ·governing element declaration· is in ED's ·substitution group· with a {type definition} similarly derived: If {prohibited substitutions} is empty, then all such substitutions are allowed, otherwise, the derivation method(s) it names are disallowed. A second fix restructures the paragraph and eliminates the suggestion that valid substitutability of types is used only in the two cases mentioned (since that is no longer true). The {prohibited substitutions} property of a complex type definition T determines whether type definitions derived from T are or are not ·validly substitutable· for T. Examples include (but are not limited to) the substitution of another type definition: - as the ·governing type definition· of an element instance E, when T is the ·selected type definition· of E (often, the declared {type definition} of E's ·governing element declaration·); this can occur when E specifies a type definition using the xsi:type attribute; see xsi:type (§2.6.1); - as the ·selected type definition· of an element instance E, when T is the declared {type definition} of E's ·governing element declaration·; this can occur when conditional type assignment is used; see Type Alternatives (§3.12); - as the ·governing type definition· of element instances whose ·governing element declaration· is included in a model group only ·implicitly·, by virtue of being included in the ·substitution group· of some element declaration included directly or indirectly in the model group, whose declared {type definition} is T. If {prohibited substitutions} is empty, then all such substitutions are allowed; if it contains the keyword restriction, then no type definition is ·validly substitutable· for T if its derivation from T involves any restriction steps; if {prohibited substitutions} contains the keyword extension, then no type definition is ·validly substitutable· for T if its derivation from T involves any extension steps. Unfortunately, the second change makes the text longer. But at the moment, at least, I don't see errors in it.
A wording proposal including changes for this issue went to the WG on 7 February 2008: http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.consent.200801.html#composition (member-only link).
The XML Schema Working Group today accepted the proposal mentioned in comment #2, which included the second of the two possible fixes mentioned in comment #1. With this change, the WG believes we have resolved this issue fully for XSD 1.1. Accordingly, I am going to - change the status of this issue to RESOLVED - FIXED - clone this issue to track the corresponding problem in 1.0 - set the status of that new issue accordingly, and add Daniel Barclay to the CC list for the new issue, as the originator of this issue Mr. Barclay, as the originator of this comment, you should receive from Bugzilla an email notification of this decision. Please accept our thanks for the bug report. Please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.
> Please let us know if you agree with this resolution of your issue, by > adding a comment to the issue record and changing the Status of the > issue to Closed. Although I don't have time to fully read, study, and confirm this fix, it appears to address the problem. (Marking closed.)