This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Assume A,B,C,D are all schema documents. A has target namespace ns1, C has target namespace ns2, B and D don't have a target namespace. Now A includes B, B imports C, and C imports D. This appears to be legal. The spec is clear that the schema corresponding to A includes components from all 4 schema documents. But what target namespace do components from D have? The current rule seems to suggest that they get ns1. But this is somewhat counter-intuitive, as D is explicitly imported without a namespace. This can be resolved by saying "chameleon include is as if the included document had a target namespace". Now the above list of schema documents become A, B', C, and D, where B' replaces B with a target namespace ns1. This rule works well for the above case. Now consider X,Y,Z where X and Z have the same target namespace ns and Y doesn't have one. X includes Y, and Y imports Z. Following the current rule, X's schema get all components from all 3 documents, and they all have the same target namespace. But if we use the above "as if" rule, this would generate an error, because Y' (with target namespace ns) now is not allowed to import Z, because they have the same target namespace. To handle this, the "as if" rule can be amended by saying "if adding target namespace introduces illegal imports like the above, treat them as if includes". We need to pick one of the 3 possible rules: what the spec has now; the "as if" rule; or the "amended as if" rule.
There's a deep root cause to all such problems, which is confusion about whether you are including a schema document or a set of components. Sometimes the spec writer seems to be under the impression that you go fetch the document, construct some components, and then include the components. That doesn't work of course because you haven't got enough information at this stage to finish constructing the components, for example you don't know the variety of a simple type until you've found its base type. For this particular problem the informal prose seems a good place to start: "the <include>d schema document is converted to the <include>ing schema document's targetNamespace." I think we get most sanity if we treat it as a syntactic transformation applied to the schema document before doing any semantic analysis or component building. That's Sandy's "as if" rule. Perhaps the XYZ corner case should be handled by simply dropping the rule that you can't import your own namespace - instead, any such import is treated unconditionally as an include.
Here is a bug entry against one of my clients products that is related to this: If we have this case: A.xsd, targetNamespace="ns1" - includs B.xsd (a chameleon) - imports C.xsd, targetNamespace="ns2" - includes D.xsd (a chameleon) - contains global type "foo" And someting in A or B refers to foo, when we generate the schema, the result will put foo into ns1, not into ns2. I'm pretty sure that this bug against my client's product is related to the uncertainty that Sandy and Mike K. refer to about what the spec requires.
With regard to the XYZ corner case mentioned in the description and in comment #1: the wording proposal the editors are sending to the WG today does not address it. If we wish to address the case, by taking up the suggestion in comment #1, the specific wording change needed would be: In Schema Representation Constraint: Import Constraints and Semantics, first move the definition of MD (module) and DD (driver) up to before clause 1. Then replace clause 1, which currently reads: 1 The appropriate case among the following must be true: 1.1 If the namespace [attribute] is present, then its ·actual value· does not match the ·actual value· of the enclosing <schema>'s targetNamespace [attribute]. 1.2 If the namespace [attribute] is not present, then the enclosing <schema> has a targetNamespace [attribute] with something like 1 If both DD and MD have targetNamespace [attribute]s with the same actual value, or if neither has a targetNamespace [attribute], then the <import> is treated in the same way as an <include> element in the same position and with the same attributes and content. And optionally add a note saying processors can issue warnings if they like: Note: conforming processors MAY choose to issue a warning if the targetNamespace [attribute]s of MD and DD fail to differ. When clause 2.3 of Schema Representation Constraint: Inclusion Constraints and Semantics is being applied, however, such warnings are unlikely to be very useful. I would put this into the proposal itself but for the fact that if I do that we will not have the proposal out today. [This suggestion is made without impairment of my conviction that until we are willing to look with fresh eyes on our schema composition story, fixing individual issues of this kind is an unwise use of our time.]
An optional alternative: if we decide NOT to adopt the proposal to remedy the XYZ alternative, we might decide to add a note warning the reader: Note: if MD imports the target namespace of DD, then the effect of clause 3.2 will be to cause an error owing to the violation of clause 1 of Schema Representation Constraint: Import Constraints and Semantics. Caution is advised.
This issue was resolved by the WG's adoption, today, of a wording proposal which also addresse bug 2067, and which changed the description of chameleon include. The approved wording has now been integrated into the status quo document; I am accordingly marking this issue as resolved. Sandy, as originator of the issue, you may wish to do the honors of changing its status from Resolved to Closed.