[Bug 5163] schemalocation needs to be cleaned up and clarified

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5163

           Summary: schemalocation needs to be cleaned up and clarified
           Product: XML Schema
           Version: 1.1 only
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: cmsmcq@w3.org
        ReportedBy: johnarwe@us.ibm.com
         QAContact: www-xml-schema-comments@w3.org


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.

Received on Monday, 8 October 2007 21:53:43 UTC