This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I was just reviewing the discussion of chameleon includes at [1]. It says: 2 One of the following must be true: 2.1 SII has a targetNamespace [attribute], and its ·actual value· is identical to the ·actual value· of the targetNamespace [attribute] of SII (which must have such an [attribute]). 2.2 Neither SII nor SII have a targetNamespace [attribute]. 2.3 SII has no targetNamespace [attribute] (but SII does). 3 The appropriate case among the following must be true: 3.1 If clause 2.1 or clause 2.2 above is satisfied, then the schema corresponding to SII must include not only definitions or declarations corresponding to the appropriate members of its own [children], but also components identical to all the ·schema components· of I. 3.2 If clause 2.3 above is satisfied, then the schema corresponding to the <include>d item's parent <schema> must include not only definitions or declarations corresponding to the appropriate members of its own [children], but also components identical to all the ·schema components· of I, except that anywhere the ·absent· target namespace name would have appeared, the ·actual value· of the targetNamespace [attribute] of SII is used. In particular, it replaces ·absent· in the following places: 3.2.1 The {target namespace} of named schema components, both at the top level and (in the case of nested type definitions and nested attribute and element declarations whose code was qualified) nested within definitions; 3.2.2 The {namespace constraint} of a wildcard, whether negated or not; Clause 2.3 seems to have effect only in the case that the including schema document has an explicit targetNamespace attribute. The result seems to be that if the included chameleon schema document itself issues an include, that grandchild schema document will not be subject to chameleon processing, even if it lacks a targetNamespace attribute. Is this intentional? If not, then probably it's a bug that should be addressed. Noah [1] http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#compound-schema
There does seem to be a bug here, but it's the use of the phrase "the schema corresponding to the <include>d item's parent <schema>" instead of "the schema corresponding to SII'" or "the schema corresponding to the <include>ing item's parent <schema>". Clause 3.2 calls for including, and performing namespace munging on, not only those components corresponding to source declarations in schema document SII, but all components in I, the schema corresponding to SII. If SII contains <xsd:include> elements pointing to other schema documents without a target namespace, the components derived from the source declarations in those schema documents are part of schema I, and are thus subject to namespace munging just like those whose source declarations are in I. The wording looks like an error only when the reader fails to observe that the rule defines the result of chameleon include not in terms of the set of source declarations from which components are to be constructed, but in terms of the schema constructed from the included schema document.
During today's call, the Working Group decided against taking action on this issue, and to close it with the disposition INVALID. That means that we do not expect any change in the 1.1 spec to address the concern raised here, because we believe that no real issue is raised. (In view of the tight time frame, this decision may be reopened and revisited on next week's call.) Accordingly, I'm marking this issue as resolved. Noah, as the originator of this issue, you can signal your agreement with (or at least: acquiescence in) this decision by marking the issue CLOSED, or you can indicate your dissatisfaction with the decision by changing the status to REOPENED. If we don't hear from you in a couple of weeks, we'll assume you acquiesce and the issue will be marked CLOSED.