- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 20 Apr 2009 17:47:35 +0000
- To: www-xml-schema-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6014 --- Comment #8 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> 2009-04-20 17:47:34 --- 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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 20 April 2009 17:47:43 UTC