This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
- Heading 3.4.2 is inconsistent with others, lacks "Schema Components" on end CTD w/ simple content: - {assertions} "in order" means in document order? in some other well-known and normative order? - {attribute uses} item 3 "base [attribute]" base is ambiguous. I "think" you mean xs:extension/@xs:base or xs:restriction/@xs:base, not xml:base (or any other bases) - {attribute uses} item 3 could use some re-wording to make it more readable. - "When the <complexContent> alternative is chosen, the following elements are relevant (as are the <attributeGroup> and <anyAttribute> elements, not repeated here), ". If you want the spec to be more consumable, repeat them. - "shorthand for complex content restricting ·xs:anyType·, and the details of the mappings must be modified as necessary." Again, be explicit or be obtuse. This kind of hand-waving just leaves room for human readers to misinterpret. CTD w/ complex content: - {content type} 2.1.3 clarify from: "There is a <choice> among the [children] with no [children] of its own excluding <annotation> whose minOccurs [attribute] has the ·actual value· 0;" to: "There is a <choice> among the [children], and none of the <choice>'s [children] has a minOccurs [attribute] with the ·actual value· 0 (excluding the <choice>'s <annotation> [children]);"
This bug is from the SML workgroup as a whole, decided at 2007-10-25 telecon.
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'.
During the teleconference of 21 March 2008, the XML Schema WG adopted a wording proposal (the 'March 2008 omnibus proposal') which we believe resolves some but not all of the issues raised in this bug report. The wording proposal can be seen at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni-200803.html (member-only link) The changes made include these: - Titles have been normalized in section 3.*.2 (with the exception of XML Representation of Particle Components (§3.9.2) the editors suffered from weak stomachs at the crucial moment and could not bring themselves to formulate the title as "XML representation of particle schema components") - "in order" changed to "in document order" in several places - Clause 3 of the rule for {attribute uses} for complex types with simple content has been recast, and the reference to the base attribute clarified (we think); note that in its current form this refomulation assumes the adoption of editorial proposal EP-24 for a 'dot operator' (currently in preparation) and must be reformulated slightly if the dot operator is not introduced. - Rule 2.1.3 of the rule for {content type} for complex types with complex content has been reformulated. But N.B. the reformulation is not the one you suggested. (You fell victim to a relative-phrase-attachment ambiguity.) Two points raised in the bug report are NOT yet dealt with, so this bug is not being marked RESOLVED but returned to 'needsDrafting': - The mapping rules for attributeGroup and anyAttribute are not repeated. - The mapping rules to be followed for complex content restricting ·xs:anyType· are not recapitulated explicitly with appropriate modifications. These changes may be made later, but the editors are ducking them for now because they look hard and because they may also interact with other changes in the presentation cluster. John, as the originator of the bug report, I hope that you will review the changes made and let us know whether they satisfactorily address the points they are intended to resolve.
> the editors suffered from weak stomachs at the crucial moment and could not bring themselves to formulate the title as "XML representation of particle schema components") If PSC is such a horrid phrase, someone will have to explain to me/us the existence of "3.9.1 The Particle Schema Component" Under the new text "The attribute uses "inherited" from the {base type definition" clause 3.2.2 from: = prohibited. to : is prohibited. > base attribute clarified (we think) Agreed. 3.2.2 is still pretty opaque, though. Should the following change be made in the new text? With all the variously delimited "attribute" words running around in 3.2.2, hard to tell. from: what would have been an attribute use to : what would have been an {attribute use} (still on 3.2.2) This _might_ help incrementally from: had not had to : had not specified I at least get one less brain fault in the latter rendering. (still on 3.2.2) Here is how I am reading it, in case I'm wildly wrong again. I might be tempted to add something like this to the new 3.2.2 text. "In other words, the case where the {base type definition} T allowed the {attribute use} but the restriction prohibits it." 2.1.3 I prefer KISS to fancy writing when things are this complex. I'm not afraid to club readers over the head a bit now and again, e.g. "There is a <choice> among the [children] from: whose minOccurs [attribute] has the ·actual value· 0 to : , the minOccurs [attribute] on the <choice> has the ·actual value· 0 from: and which has no [children] of its own to : , and the <choice> has no [children] of its own except for <annotation>;" i.e change from "There is a <choice> among the [children] whose minOccurs [attribute] has the ·actual value· 0 and which has no [children] of its own except for <annotation>;" to "There is a <choice> among the [children], the minOccurs [attribute] on the <choice> has the ·actual value· 0, and the <choice> has no [children] of its own except for <annotation>;" While the "from" version is smaller in size, syllables, etc., the zeal with which it tries to conserve space resembles "how few [incomprehensible] lines of C code can you do X in?" While I prefer the "to" version, I will not protest if the editors/wg prefer the "from" version. On the whole, yes good job vs the intent.
On its telecon of 2009-04-27, the SML working group expressed consensus that there were zero objections to Schema deferring resolution of this bug until after the CR drafts are issued.
Discussed on 2009-07-24 telcon.
A draft wording proposal for bug 5156 is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5156e.html
The wording proposal mentioned in comment 7 was adopted, with minor amendments, on today's XML Schema working group call and has been integrated into the status quo document. The amendments were: In 3.4.2.3.3, change clause 2.1.3 by: - deleting the first (old) version of the sentence (thus correcting an error in preparing the proposal) - change 'with minOccurs = 0 and with' to the old formulation, 'whose minOccurs attribute has the actual value 0 and which has' In the Note added in 3.4.2.4, change 'allowed' to 'allows'. I'm marking this resolved. John, as the originator, you and the SML WG have the right to express an opinion in the usual way. Two weeks, and we'll assume you're happy.
So I can explain this correctly to the SML wg, am I correct in thinking that the wording proposal in comment 7 handles the issues raised in comment 4 in the following ways? > If PSC is such a horrid phrase, someone will have to explain to me/us the > existence of "3.9.1 The Particle Schema Component" no response > to : is prohibited. no change made (looking the wording proposal, fwiw I'd agree with "no change") > to : what would have been an {attribute use} no change made > to : had not specified no change made > (still on 3.2.2) Here is how I am reading it, in case I'm wildly wrong again. > I might be tempted to add something like this to the new 3.2.2 text. > "In other words, the case where the {base type definition} T allowed the > {attribute use} but the restriction prohibits it." note added, wording amended in comment 8 > 2.1.3 I prefer KISS to fancy writing when things are this complex. no change made
Per http://lists.w3.org/Archives/Public/public-sml/2009Nov/0001.html , the SML working group has unanimous consensus that this resolution is acceptable.