This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation says "The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide hints" In the downstream sections however, xsi:schemaLocation is not always a hint, as this could be read to suggest. 4.2 notes "Note: In the sections below, "schemaLocation" really belongs at layer 3. For convenience, it is documented with the layer 2 mechanisms of import and include, with which it is closely associated." This is pretty non-sensical, unless you are saying that the existing abstractions are broken/cross layers. 4.2.2 Schema Representation Constraint: Inclusion Constraints and Semantics item 1 has 2 cases, each of which result in a D2. All the sub-cases of items 2 and 3 depend upon a D2 being created, however item 1 is conditional on the resolution of the schemalocation so it does not always result in a D2. If the resolution step in item 1 fails, no action or result is specified. The first sentence AFTER this constraint however does appear to specify a result: "It is not an error for the ·actual value· of the schemaLocation [attribute] to fail to resolve at all, in which case no corresponding inclusion is performed." It appears "no...is performed" should be "...MUST NOT be performed". This suggests that the constraint's item 1 should also say that if resolution fails a "null" D2 is created (presumably with an absent namespace and no schema components). "Schema Representation Constraint: Import Constraints and Semantics" avoids this via the "If D2 exists," in item 3. 4.2.2 requires the schemalocation, but allows it not to resolve. Contrast the words here with those found in 4.2.4.1 and 4.2.4.2. 4.2.4.1 explicitly says "Note that components to be imported need not be in the form of a ·schema document· and need not in particular be declared in the particular schema document identified by a schemaLocation attribute; the processor is free to access or construct components using means of its own choosing, whether or not a schemaLocation hint is provided." It is currently ambiguous whether this same statement applies to <include> or whether a stronger one applies to <include>. Similarly, 4.2.4.2 says "Providing Hints for Schema Document Locations The ·actual value· of the schemaLocationattribute, if present on an <import> element, gives a hint as to where". Again, 4.2.2 leaves it unspoken whether the intent is to have the same weak relationship between schemalocation and the referenced schema components, or a stronger one. I.e. can a processor "ignore" schemalocation, perhaps simply by assuming it never resolves, and then fall back on implementation-dependent sources for the schema components (as is explicitly allowed for import) or is a compliant processor's behavior further restricted for include? The heading 4.2.4.2 Providing Hints for Schema Document Locations itself could be read to imply a broad general treatment of schemalocation, although it is nested under 4.2.4 (import only). In this case, changing the heading from: "4.2.4.2 Providing Hints for Schema Document Locations" to : "4.2.4.2 Providing Hints for Imported Schema Document Locations" would help clarify its intended scope. 4.2.4.2 mentions conformance profiles further restricting schemalocation. Is this specific to import (the context would suggest so) or not (logic would suggest so). "Conformance profiles may further restrict the use of the schemaLocation attribute." 4.2.4.2 "When a schemaLocation attribute is present, it must contain a single URI reference which the schema author warrants will resolve to a serialization of a ·schema document· containing component(s) in the <import>ed namespace." Does this same warrant apply to include or not? The nesting suggests not, logic would suggest otherwise. Bottom line, there are a lot of inconsistencies in the treatment of schemalocation and it would be very helpful to clarify the intent. The import section even does a decent job of dancing around the layer 2/3 issues. Maybe it would make sense to factor the bulk of its schemalocation content out, if they really are intended to be (mostly) consistent.
This bug is from the SML workgroup as a whole, decided at 2007-10-25 telecon.
Editors to check the minutes for the afternoon of 2008-01-24 for details of the decision. RESOLUTION: bug 5163 to be marked NEEDS DRAFTING
Since the issues raised here appear all to involve clarification, rather than modification, of the substantive rules of the spec, I'm marking this issue as 'editorial'.
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.
Discussed on 2009-07-24 telcon. 2.6.3 1) xsi:schemaLocation is always a hint. 2) xs:schemaLocation is not. 4.2 Skip.
On the XML Schema WG call today, the WG adopted the wording proposal at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5163.html as a resolution of this issue. Once it has been integrated into the status-quo document, this issue will be marked resolved.
The wording proposal mentioned in comment 6 has now been integrated into the status quo documents, so I am marking this issue resolved. John, if you could report this resolution back to the SML Working Group and let us know whether you and they are happy with the resolution of the issue or not, it would be helpful. Close the issue to indicate assent, reopen it to indicate dissent (and explain what's wrong). If we don't hear otherwise from you by mid-September, we will assume that you are happy with the resolution of the issue.
Speaking for myself only: looks mahvelous. Have queued it up with SML wg for resolution this week (assuming no objections).
(In reply to comment #8) No objections to the proposed resolution were raised by the SML working group to the proposed resolution. Accordingly, closing this out.