This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
1.5 Documentation Conventions and Terminology - deprecated from: although some processors may choose to issue to : although some processors MAY choose to issue 3.12.3 Constraints on XML Representations of Type Alternatives "No <alternative> element may have more than one of these, and each must have at least one of these. " No...MAY seems destined to be mis-read. Feels like it wants to be a MUST (have at most one), prefer this, or MUST NOT (have >1) 4.2.1 Conditional inclusion "Where they appear, the attributes vc:minVersion and vc:maxVersion are treated ... then the element on which the attribute appears is to be ignored" Does anyone really think describing things in terms of what it's not (i.e. negatively) is better than positively? Realizing where you are in the process, since I think this IS correct as stated (though it took several passes for me to catch the not's and un-'s I missed the first time), I'd settle for a non-normative summary stated in the "include if" positive sense. 4.2.2 Assembling a schema <include> clause 1 "It is not an error for the ·actual value· of the schemaLocation [attribute] to fail to resolve at all, in which case the corresponding inclusion must not be performed." why maintain this unpleasant dark corner, if redefine and override etc all want to mandate resolution? is this just FUD masquerading as backward compatibility, or are there well-known concrete scenarios that depend on this behavior? 4.2.4 Overriding component definitions Schema Representation Constraint: Override Constraints and Semantics clause 4.1.1, 4.2.1 "Let D2' be a <schema> information item obtained by . Then ..." ??? something missing 'by .' 4.2.4 Overriding component definitions Schema Representation Constraint: Override Constraints and Semantics clause 4.1.2 "Note: One effect of the rule just given..." I cannot tell, due to previous comment's missing text 4.2.4 Overriding component definitions Schema Representation Constraint: Override Constraints and Semantics clause 4.1.2 "Note: Another effect is..." You handle A <override> B <override> C It's not clear if there is deterministic behavior in the Y case: both B and C <override> A with conflicting specifications. <include> clause 3.1.2 in particular, if 2.1 fires, seems to tell me I cannot "build up" a ns with components from several non-overlapping <schema> items...since I think this is possible today, not convinced I'm reading it right. It also sounds like it prescribes an order of processing, but I had the impression that different orders were permissible (lazy retrieval strategies) which seems to conflict with that impression. 5.2 Assessing Schema-Validity - strict ..."if they do not identify any declaration or definition, then no schema-validity assessment is performed. " This appears to say that the result is implementation-dependent. I rather expected some prescribed output, either an error or values for [validation attempted] etc.
I'm marking this as editorial, since almost all of the points raised involve rephrasing the wording to make it clearer and eliminate apparent contradictions. Two points probably require special treatment: the comment on 4.2.2 and schema composition probably should be discussed by the WG (although speaking for myself I see little probability that the WG will be able to do more than shrug and say "we haven't been able to clear up this dark corner in six years of trying; we don't know any more now than we did then" and reaffirm its decision to leave the Augean stables of schema composition uncleansed). The comment on 5.2 intersects with another issue I have been intending to raise personally, and will be pointed to from that issue.
The SML working group did not choose to endorse (or not to endorse) this bug on its call of 2008-09-11
A response to these comments has been sent via email and is archived at http://lists.w3.org/Archives/Public/www-xml-schema-comments/2009AprJun/0064.html The changes proposed as resolutions of some of the points raised in the bug report can be seen in context at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6014.html (member-only link) and await WG action.
6014 (John Arwe): Proposal for issue 6014 [schema11] normative text problems http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6014.html Summary: straightforward clarifications and corrections. MSM's recommendation: adopt quickly, without discussion. Ammendment: <cmsmcq_> in 3.12.3, make second sentence of the relevant paragraph read: <cmsmcq_> Each <alternative> element MUST have one and only one of these.
The changes described in comment 4 have now been integrated into the status-quo documents. John, if you would indicated in the usual way whether you are satisfied or dissatisfied with the disposition of the comments, it would be helpful. If we don't hear from you in ten days we will assume you to be content.
(In reply to comment #5) > The changes described in comment 4 have now been integrated > into the status-quo documents. It appears the amendment from comment #4 was not incorporated as stated (although the spirit appears the same, comment #4's amendment is clearer to me). The rest seems fine. > It's not clear if there is deterministic behavior in the Y case: both B and C > <override> A with conflicting specifications. I'm not clear how the logical grouping of A <override> B <override> C is forced to be A + (B + C) but I have to believe it for now.
> I'm not clear how the logical grouping of A <override> B <override> C is forced > to be A + (B + C) but I have to believe it for now. I see now it is artfully described in Appendix G. I will leave the state of this bug alone to signal the editors that comment #6 reflects a -possible- to-do for the editors to integrate the text described in the amendment contained in comment #4. If the editors are either happy with the text as it currently is, or if the editors choose to integrate the text described in the amendment contained in comment #4, then this bug may be immediately closed as satisfying me without further review on my part (and since this bug was not endorsed by the SML wg, "that is all").
John Arwe says in comment 6: It appears the amendment from comment #4 was not incorporated as stated (although the spirit appears the same, comment #4's amendment is clearer to me). I may be missing something, or looking in the wrong place. But comment 4 says, I think: In 3.12.3, make second sentence of the relevant paragraph read: Each <alternative> element MUST have one and only one of these. In the status-quo document, the paragraph which is the entire text of Schema Representation Constraint: Type Alternative Representation OK reads: In addition to the conditions imposed on <alternative> element information items by the schema for schema documents, every <alternative> element must have a type attribute, or a complexType child element, or a simpleType child element. Each <alternative> element MUST have one and only one of these. That looks to me as if the amendment in comment 4 was executed correctly: the second sentence of the paragraph reads "Each ... these." (I find myself thinking of an old Doonesbury strip in which Zonker asks Honey "OK, which one of us is stoned this time?") He also asks about associativity of override. I'm not clear how the logical grouping of A <override> B <override> C is forced to be A + (B + C) but I have to believe it for now. Actually, I believe the semantics of override are such that A override B override C = (A override B override) C = A override (B override C) I don't have time or space to lay out the details here, but those with member access to the W3C site can find further information in a series of emails to the archive, pointed to from http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Jan/0004.html I notice there's a typo there, so I'll repeat the pointers here: http://lists.w3.org/Archives/Member/w3c-archive/2009Jan/0053.html http://lists.w3.org/Archives/Member/w3c-archive/2009Jan/0054.html http://lists.w3.org/Archives/Member/w3c-archive/2009Jan/0058.html You will want to read those notes (at least the description of the notation and a couple simple examples) before continuing. In the notation developed there, the example you mention is A overrides B with E1 B overrides C with E2 There are two cases: E1 and E2 are disjoint, or overlap. Either way, the formulaic notation provides this summary: schema(A) = b + dir(A) + schema(over(E1,B)) = b + dir(A) + b + dir(over(E1,B)) + schema(over(E1,over(E2,C))) = b + dir(A) + dir(over(E1,B)) + dir(over(E1,over(E2,C))) If E1 and E2 are disjoint, it clearly doesn't matter if the two sets of overrides to C are done in one sequence, or the other, or at the same time. If E1 and E2 overlap (let us assume each is a redefinition of an element E), it matters that schema(A) includes version E1, not version E2. If we evaluate (A override B) first, we end up with the equivalent of A include B' B' overrides C with E1 because the required transformation will override the E2 in the override element in B. If we evaluate (B override C) first, we end up with the equivalent of A override B' with E1 B' include C' C' = over(E2,C) The transitive effect of the required transformation requires that the override of B' with E1 turn into both an override of the declarations directly within B and an override of those in C', because C' is included by B.
(In reply to comment #8) > (I find myself thinking of an old Doonesbury strip in which > Zonker asks Honey "OK, which one of us is stoned this time?") The effect, if not the cause, I can safely plead guilty to (first nice weekend since the trees started blooming). I was intertwingling (you might recognize that, it's a technical term) it with the "exactly one" change for <choice>'s Disjunction &whatever. > I don't have time or space to lay out the details here, but those I'm glad you didn't spend time doing so, especially given comment #7 which likely crossed paths in the email stream.