This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following sets of passages either definitely are, or appear to be, contradicting one another. 3.3.2 XML Representation of Element Declaration Schema Components There are some subtle inconsistencies to be worked out. - There is no equivalent to the two paragraphs in 3.3.2 starting with "<element> corresponds to an element declaration," in 3.2.2 (Attributes), although the rest seems to correspond. - "<element>s within <schema> produce global element declarations;..." vs text later in 3.3.2 on mapping rules that says "If the <element> element information item has <schema> as its parent, it maps to an Element Declaration". Note that 'global' was dropped. 3.3.2.1 Common Mapping Rules for Element Declarations - XML Mapping Summary clause 2 "2 otherwise (the <alternative> has a test) a Type Alternative with the following properties: Property {test} Value ·absent·." vs 3.3.6.1 Element Declaration Properties Correct clause 6 "6 If E.{type table} exists, then for each Type Alternative in E.{type table}.{alternatives}, the {test} property is not ·absent·. " 3.3.2.1's tableau seems to say there is a "default type definition", i.e. if the final <alternative> has no @test. 3.3.6.1 seems to be saying that case is always INvalid. 3.1.1 Components and Properties "Equality of components for the purposes of this specification is always defined as equality of names (including target namespaces) within symbol spaces." vs 1.5 Documentation Conventions and Terminology 'For components C1 and C2, an expression..."C1 = C2" means that C1 and C2 are identical,...' I *think* these two are actually OK, but probably only because 'identical' is not well-defined. If it were, it would likely based on context be defined as having recursively equal properties, in which case we are no longer talking about simple <ns,name,symspace> equality. It would essentially be (3.17.5.1 Schema Information) item isomorphic 4.2.4 Overriding component definitions Schema Representation Constraint: Override Constraints and Semantics clause 4.1.2 "4.1.2 The <override> element ... inclusion is handled as described in ... (<include>) (§4.2.2). " I think you want me to read the "If...resolves" in <include> clause 1 as being constrained by 4.2.4 clause 1 (MUST resolve if not vacuous). I'm not sure you have actually forced this for all language lawyers. It seems like I could take your constraints as a recipe for execution, i.e. I execute <override> clause 1 (URI resolves), eventually come down to <override> clause 4.1.2, as part of its execution I call <include> clause 1 (URI no longer resolves), and that's just fine by the letter of what you wrote it appears.
Thank you; these are useful points.
The SML working group chose to endorse this bug on its call of 2008-09-11
During its 2009-03-20 and 2009-04-03 telecons, the schema WG discussed comments raised in this bug report and adopted the following resolutions. Some of the proposed changes can be found at (member-only): http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni.20090313.html With these changes, the WG believes that the issue raised in this bug report is fully addressed. I'm marking this RESOLVED accordingly. John, as the persons who opened and reopened this issue, if you would indicate your concurrence with or dissent from the WG's disposition of the comment by closing or reopening the issue, we'll be grateful. If we don't hear from you in the next two weeks, we'll assume that silence implies consent. > 3.3.2 XML Representation of Element Declaration Schema Components > There are some subtle inconsistencies to be worked out. > - There is no equivalent to the two paragraphs in 3.3.2 starting with > "<element> corresponds to an element declaration," in 3.2.2 (Attributes), > although the rest seems to correspond. Equivalent paragraphs added to 3.2.2. > - "<element>s within <schema> produce global element declarations;..." vs text > later in 3.3.2 on mapping rules that says "If the <element> element > information item has <schema> as its parent, it maps to an Element > Declaration". Note that 'global' was dropped. Added "global" in 3.3.2. (Not shown in the above link.) > 3.3.2.1 Common Mapping Rules for Element Declarations - XML Mapping Summary > clause 2 > "2 otherwise (the <alternative> has a test) a Type Alternative with the > following properties: Property {test} Value ·absent·." > vs 3.3.6.1 Element Declaration Properties Correct clause 6 > "6 If E.{type table} exists, then for each Type Alternative in E.{type > table}.{alternatives}, the {test} property is not ·absent·. " > 3.3.2.1's tableau seems to say there is a "default type definition", i.e. if > the final <alternative> has no @test. > 3.3.6.1 seems to be saying that case is always INvalid. No change was made for this comment. At the syntax level, the last <alternative> element in schema documents may or may not have a "test" attribute. If it does, then it maps to one of the {type table}.{alternatives}. If it doesn't, then it maps to {type table}.{default type definition}. As a result, {type table}.{alternatives} always have a {test} property (to satisfy 3.3.6.1). Note that the rule in 3.3.6.1 applies to schema components, not schema documents, and it applies to {type table}.{alternatives}, and not {type table}.{default type definition}. > 3.1.1 Components and Properties > "Equality of components for the purposes of this specification is always > defined as equality of names (including target namespaces) within symbol > spaces." > vs 1.5 Documentation Conventions and Terminology > 'For components C1 and C2, an expression..."C1 = C2" means that C1 and C2 are > identical,...' > I *think* these two are actually OK, but probably only because 'identical' is > not well-defined. If it were, it would likely based on context > be defined as having recursively equal properties, in which case we are no > longer talking about simple <ns,name,symspace> equality. > It would essentially be (3.17.5.1 Schema Information) item isomorphic Dropped the sentence in 3.1.1, as it causes confusion and isn't actually used. > 4.2.4 Overriding component definitions > Schema Representation Constraint: Override Constraints and Semantics clause > 4.1.2 > "4.1.2 The <override> element ... inclusion is handled as described in ... > (<include>) (§4.2.2). " > I think you want me to read the "If...resolves" in <include> clause 1 as being > constrained by 4.2.4 clause 1 (MUST resolve if not vacuous). > I'm not sure you have actually forced this for all language lawyers. It seems > like I could take your constraints as a recipe for execution, i.e. I execute > <override> clause 1 (URI resolves), eventually come down to <override> clause > 4.1.2, as part of its execution I call <include> clause 1 (URI no longer > resolves), and that's just fine by the letter of what you wrote it appears. <override> has been changed so that the same changes (as specified by <override>) are applied to not only the document being overridden directly, but also documents it includes/overrides. Consider the case where A overrides B includes C. After applying the transformation to the "override", it becomes A includes B' overrides C. After transforming the new "override", it becomes A includes B' includes C'. Because "B includes C" was allowed to not resolve, we do not want to require that "B' overrides C" to resolve. WG decided to drop clause 1 from the <override> section (which requires schema location resolution for non-empty <override>), to make it align better with <include>.
(In reply to comment #3) > Some of the proposed changes can be found at (member-only): "Some"?? So you're asking me, and the wg, to say whether or not the omnibus addresses the issues raised in this bug w/o seeing all of the related changes? In the words of Monty Python: that's odd ... and a bit suspect I think. > John, as the persons who opened and reopened this issue, if you would indicate > your concurrence with or dissent from the WG's disposition of the comment by Given the 1 hr/week frequency of SML wg meetings at the moment, I am unsure that the wg will respond w/in 2 weeks. > Equivalent paragraphs added to 3.2.2. I'm not seeing them at the URI provided. No highlighting in 3.2.2, and a skim for the first few words + search for "global" does not find them either. > Added "global" in 3.3.2. (Not shown in the above link.) I'm willing to believe :-) > > 3.3.2.1 Common Mapping Rules for Element Declarations - XML Mapping Summary > > clause 2 > No change was made for this comment. ok > Dropped the sentence in 3.1.1, as it causes confusion and isn't actually used. Still in the draft of the URI provided. > that "B' overrides C" to resolve. WG decided to drop clause 1 from the > <override> section (which requires schema location resolution for non-empty > <override>), to make it align better with <include>. > Still in the draft of the URI provided, although your explanation makes sense insofar that it provides better internal consistency. It's unfortunate that the "may not resolve" nature of <include> is what we have to be consistent with (that's a visceral statement, not an implementation-based one). Based on what I do/don't see (mostly the latter) at the URI provided, I see little point in asking the SML wg if they are satisfied with these changes. I think I would be satisfied with them once visible in a draft, i.e. the resolutions themselves seem ok, but until a draft showing them in situ is visible I would not personally be comfortable signing off on them.
Oops, wrong link. It should be: http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni.20090320.html > > Some of the proposed changes can be found at (member-only): > > "Some"?? I should have been clearer. The proposal above contains most of the changes, except for the insertion of the word "global", which the WG decided to add after reviewing the linked proposal. (As indicated in the proposal, it also includes changes suggested for other bugs. But those other changes should be very easy to identify.)
(In reply to comment #5 (for URI value) and comment #3 (for list of changes)), and replying for now strictly on my own behalf since the SML wg has not yet been consulted... > http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni.20090320.html 3.2.2: I think you need to read the added text again carefully and look especially at any place you use "element". They look very much like cases of copy & (missed) tweak. 3.3.2: just before the unrelated add of "global", and after GED has been defined, you use the phrase "For complete declarations, top-level or local," (top-level vs global). I'd suggest you replace top-level with global unless there is some contextual reason not to (and this is merely a suggestion; I give the wg and editors full license to ignore or heed it with no further tracking back to me). > Dropped the sentence in 3.1.1, as it causes confusion and isn't actually used. While it may be true that dropping the sentence removes the inconsistency, doing so also gives less reinforcement for the meaning of "identical" in 1.5. "Identical" is in turn used to define the meaning of a fairly central notation. My sense is that the intent of "identical" was in fact quite similar to the (more precise and explicit) definition of "item isomorphic"; if that is the case, I would encourage some linkage to be drawn (even the dreaded forward reference). If the wg is comfortable as it stands in the omnibus draft, I can live with that as well. While I see some room for misinterpretation or ambiguity, I think the actual probability of that leading to competing and conflicting assertions grounded securely in the spec is small. On the rest, covered earlier, I'm ok with the wg's decisions.
A wording proposal intended to resolve the remaining issues of this bug report is now on the server at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6012b.html (member-only link) and awaits WG action. Further comments on individual items: > 3.2.2: I think you need to read the added text again carefully > and look especially at any place you use "element". They look > very much like cases of copy & (missed) tweak. Fixed. Thanks. > 3.3.2: just before the unrelated add of "global", and after GED > has been defined, you use the phrase "For complete > declarations, top-level or local," (top-level vs global). I'd > suggest you replace top-level with global unless there is some > contextual reason not to (and this is merely a suggestion; I > give the wg and editors full license to ignore or heed it with > no further tracking back to me). I understand SG to be trying (against some resistance from the spec) to use 'top-level' consistently to refer to source-level element declarations which are children of 'schema' (or 'redefine' or 'override') and 'global' to refer to components which have global scope. Since the two classes correspond to each other, the terms are sometimes used interchangeably and he's fighting an uphill battle. I've recast the paragraph to try to make it easier for non-theologians to tell when it's talking about source declarations and when it's talking about ocmponents. >> Dropped the sentence in 3.1.1, as it causes confusion and >> isn't actually used. > While it may be true that dropping the sentence removes the > inconsistency, doing so also gives less reinforcement for the > meaning of "identical" in 1.5. "Identical" is in turn used to > define the meaning of a fairly central notation. My sense is > that the intent of "identical" was in fact quite similar to the > (more precise and explicit) definition of "item isomorphic"; if > that is the case, I would encourage some linkage to be drawn > (even the dreaded forward reference). If the wg is comfortable > as it stands in the omnibus draft, I can live with that as > well. While I see some room for misinterpretation or > ambiguity, I think the actual probability of that leading to > competing and conflicting assertions grounded securely in the > spec is small. I think it would be saying too much to say that the WG is "comfortable" with the treatment of component identity in either XSD 1.0 or XSD 1.1, but the chances of changing the situation appear remote. I won't go into details; let's just say the WG has spent some time trying to agree on questions related to component identity, and after a while the chair concluded that these discussions were unlikely to lead to consensus within the time frame envisaged for the completion of XSD 1.1. > On the rest, covered earlier, I'm ok with the wg's decisions. Thank you.
Thanks Michael for your proposal in comment #7. Some comments: 1. Changes to the "attribute" section. The top-level/global change looks good. The new words "(i.e. those which appear within the schema document as children of <schema>, <redefine>, or <override> elements)" isn't very accurate. <attribute> isn't allowed in <redefine>, and <attribute> in <override> don't always correspond to components. 2. Changes to the "element" section. If we make the "corresponds to" -> "maps to" change, then we need the same change for "attribute". (One aspect of this bug is consistency between the 2 sections.) Obviously the same redefine/override comment applies to "element".
(In reply to comment #7) > http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6012b.html FYI: this ends at 3.3.2.4 I was expecting it would be a diff for all changes related to this bug (possibly along with others), so SML wg members do not have to chase multiple copies. > I understand SG to be trying (against some resistance from the > spec) to use 'top-level' consistently to refer to source-level > element declarations which are children of 'schema' (or This is an improvement, thanks. The first clause appears to amount to a definition of global (and/or top-level) element declarations (e.g. the bold "global"), yet it lacks the usual [Definition: ...] markup. Suggest the usual markup should be used, and in the definition I'd suggest linking top-level and global explicitly (until the rest of the spec has been weaned of the dichotomy, which might take years)... not sure if the terms being defined are "global/top-level" or the same + "element declaration", but it seems that the definition could be factored out if you like.
6012 (John Arwe and SML WG): [schema11] inconsistencies in text. Followup proposal to take care of some remaining problems. http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6012b.html SG's recommendation: Already an CR item. Proposal available. MSM'S recommendation: fairly quick - In 3.2.2 and 3.3.2, s/, <redefine>, or <override>// - In 3.2.2 in first paragraph after feedback request change "<attribute> corresponds to an attribute declaration, and allows" to "An <attribute> element maps to an attribute declaration and allows" - In 3.3.2 s/, and allows/ and allows/ - Decline John Arwe's suggestion to define 'top-level' as a defined term. (Good idea, later. Too much work for now.) - Adopt proposal as amended as full resolution (with earlier work taken into account) of 6012.
The changes adopted at yesterday's XML Schema WG telcon and detailed in comment 10 have now been integrated into the status quo document at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html With that, the XML Schema WG believes this issue to have been resolved. John, and SML colleagues, if you would do the honors in the usual way, we would be grateful. If we don't hear from you in the next ten days or so we will assume that silence implies euphoric consent.
I (personally) am good with the changes. I will put it on the SML agenda for 4/27.
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.
On its telecon of 2009-08-10, the SML working group expressed consensus that there were zero objections to the resolution proposed. Accordingly, I am closing this bug.