3889 2006-10-30 15:26:08 +0000 3.3.1 incorrect use of "respectively" (editorial) 2010-11-10 16:59:59 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only All All CLOSED FIXED http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cvc-wildcard-namespace editorial cluster P4 minor --- 5467 1 dsb cmsmcq cmsmcq David_E3 www-xml-schema-comments oldest_to_newest 12662 0 dsb 2006-10-30 15:26:08 +0000 Regarding _XML_Schema_Part_1:_Structures_Second_Edition at http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/: In section 3.3.1, the specification says: The explicit values of {substitution group exclusions} rule out element declarations having types which are extensions or restrictions respectively of {type definition}. The use of "respectively" appears to be broken (incorrect). The sentence does not contain any words identifying the pair of things that "extensions" and "restrictions" correspond to respectively (i.e., according to their order in the sentence). ("Respectively" needs to be used with at least two pairs, as in "hot" and "cold" refer to temperatures that are higher and lower, respectively.) 18723 1 cmsmcq 2008-02-04 16:17:24 +0000 In an effort to make better use of Bugzilla, we are going to use the 'severity' field to classify issues by perceived difficulty. This bug is getting severity=minor to reflect the existing whiteboard note 'easy'. 18855 2 cmsmcq 2008-02-08 02:19:34 +0000 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). 18917 3 cmsmcq 2008-02-08 20:23:45 +0000 The XML Schema Working Group today accepted a proposal to resolve this issue (for XSD 1.1) by revising the paragraph. Before the change, the paragraph read: An empty {substitution group exclusions} allows a declaration to be named in the {substitution group affiliations} of other element declarations having the same declared {type definition} or some type derived therefrom. The explicit values of {substitution group exclusions} rule out element declarations having types which are extensions or restrictions respectively of {type definition}. After the change, the paragraph reads: An empty {substitution group exclusions} allows a declaration to be named in the {substitution group affiliations} of other element declarations having the same declared {type definition} or some type derived therefrom. The explicit values of {substitution group exclusions}, extension or restriction, rule out element declarations having types whose derivation from {type definition} involves any extension steps, or restriction steps, respectively. Daniel Barclay, as the originator of this comment, you should receive from Bugzilla an email notification of this decision. Please accept our thanks for catching this problem. 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. Note that a clone of this issue for XSD 1.0 has been created in bug 5467. 19163 4 dsb 2008-02-21 02:52:26 +0000 > 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. The change addresses the problem I reported. However, something doesn't seem quite right about the improved sentence: The explicit values of {substitution group exclusions}, extension or restriction, rule out element declarations having types whose derivation from {type definition} involves any extension steps, or restriction steps, respectively. Something seems unclear about the word "explicit" there. Does it really differentiate from anything implicit? Although the block _attribute_ could be considered to implicitly contain set member values implied by a blockDefault attribute, for the {substitution group exclusions} _property_, the set member values are always explicit defined (by the Element Declaration Schema Component representation table in section 3.3.2). Is it possible that that occurrence of "explicit" was meant to be some other word that referred to the individual values that can appear in the set values of the property (as opposed to the possible set values themselves ({}, {restriction}, {extension}, {restriction, extension}))? Would something like this be better?: The value extension or restriction in {substitution group exclusions} rules out element declarations having types whose derivation from {type definition} involves any extension steps or any restriction steps respectively. Daniel 19336 5 cmsmcq 2008-03-07 00:50:16 +0000 Thank you for your response; apologies for the slow reply. I wonder whether the word 'explicit' was first introduced to distinguish the values 'extension' and 'restriction' from keywords like 'all'; if so, of course, it's an unnecessary precaution since the sentence is talking about the component level, not the XML source declaration level. It stayed in the revised sentence for no better reason than that I didn't think to take it out. I agree that your suggested alternative is an improvement, although something about the use of the singular troubles me and I lean toward When the values extension and restriction apear in the {substitution group exclusions} property, they rule out element declarations having types whose derivation from {type definition} involves any extension steps or any restriction steps, respectively. While this proposal has not received review by the other editors, I expect that it, or something like it, will go to the WG along with other small changes at some early date. If you can live with this wording, please let us know. And thank you again. 24989 6 cmsmcq 2009-05-01 18:40:12 +0000 This is the 1.1 version of this bug; see 5467 for the 1.0 equivalent. 42351 7 David_E3 2010-11-10 16:59:59 +0000 The WG reported this bug as FIXED on 2009-05-01. We are closing this bug as requiring no futher work. If there are issues remaining, you can reopen this bug and enter a comment to indicate the problem. Thanks very much for the feedback.