This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This bug takes one aspect of bug #6513 which appears to be separable from the rest of the discussion. This also relates to bug #5738. Specifically: (a) the text does not clearly distinguish between a schema and a schema document. It talks of a "schema" having a target namespace and a location, whereas those are actually properties of a schema document only. (b) the text does not make it clear whether all the elements, attributes, and types in the referenced schema are imported, or only those in the specified target namespace. (c) the text does not deal adequately with multiple imports of overlapping schemas. For example, it makes it an error if multiple imported schemas contain definitions for the same name in the same symbol space: but multiple imported schemas will *always* overlap in that sense, if only because they always contain the built-in types such as xs:integer; in practice it is also highly likely that there will be other overlaps, such as the definitions in the xml namespace. Note that from previous WG discussion of the referenced bugs, there appears to be a consensus in the WG that schema import should add to the static context of the module all the elements, attributes, and types from the schema obtained by expanding xs:include and xs:import declarations in the referenced schema documents transitively. This will be taken as the starting point, even though the existing text might appear to suggest that it only imports those elements, attributes, and types whose target namespace is equal to the target namespace explicitly specified in the "import schema" declaration.
Solving these problems is not trivial. XSLT 2.0 solves the overlap problem (c) by defining the semantics in terms of a "synthetic schema document" consisting of a number of xs:import declarations corresponding to the xsl:import-schema declarations in the stylesheet, and then saying that the schema corresponding to this synthetic schema document must be valid according to the XSD 1.0 schema composition rules. Unfortunately XQuery has ruled out this approach by the curious decision to allow multiple schema location hints, which have no parallel in the XSD schema composition rules and therefore prevent the specification delegating to the XSD spec in this way. A better approach might be for each "import schema" to be processed independently, and for the conflict rule then to specify that the union of the schemas is formed, in a way that takes account of schema component identity: this concept is left somewhat undefined in XSD 1.0, but the effective rule applied by most processors is that two components with the same name in the same symbol space are considered identical (and therefore no conflict arises) if they were constructed from the same source element in the same schema document (as identified by its absolute URI). However, the existing text already forms the union of the imported schemas before determining schema validity, so we need to retain that. PROPOSAL Here is proposed revised text for the section. [21] SchemaImport ::= "import" "schema" SchemaPrefix? TargetNamespace SchemaLocation? [21a] TargetNamespace ::= URILiteral [21b] SchemaLocation ::= "at" URILiteral ("," URILiteral)* [22] SchemaPrefix ::= ("namespace" NCName "=") | ("default" "element" "namespace") [Definition: The schema import declarations within a module collectively import the element declarations, attribute declarations, and type definitions from a schema into the in-scope schema definitions of the containing query module.] The schema that is imported is the union of the schemas corresponding to each of the individual import schema declarations in the module. It is a static error [err:XQST0035] if this union cannot be formed as a valid schema because of conflicts between the individual schemas: for example, if the union contains two or more non-identical components with the same expanded name in the same symbol space. (Note that component identity in [XSD 1.0] is left to some extent implementation-defined.) The element declarations, attribute declarations, and type definitions in this combined schema are added to the in-scope schema definitions of the module, whether or not their target namespace property is the same as any of the target namespaces listed in the import schema declarations. When a module M imports another module N, the in-scope schema declarations of N are not automatically added to the in-scope schema declarations of M. However, since the rules for schema composition in [XSD 1.0] do not preclude the addition of schema components from implementation-defined sources, implementations *may* add additional schema components to the in-scope schema components of a module, beyond those that are mandated by these rules. The schema that is imported by a single import schema declaration may be identified in an implementation-dependent way from knowledge of the target namespace given in the TargetNamespace URILiteral, or it may be constructed from a set of schema documents by following the rules for schema composition given in section 4 of [XSD 1.0], starting with the schema documents referenced by the URILiterals in the SchemaLocation clause if present. These URILiterals are optional location hints, and *may* be interpreted or disregarded in an implementation-dependent way. Multiple location hints might be used to indicate more than one possible place to look for the schema or multiple physical resources to be assembled to form the schema. Each location hint that is used by the implementation *must* identify a schema document whose target namespace is the namespace given in TargetNamespace (or is absent if the URILiteral given in TargetNamespace is the zero-length string) [err:XQST0059]. The schema import declaration may bind a namespace prefix to the specified target namespace, or may declare that target namespace to be the default element/type namespace. The namespace prefix specified in a schema import must not be xml or xmlns [err:XQST0070], and must not be the same as any namespace prefix bound in the same module by another schema import, a module import, a namespace declaration, or a module declaration [err:XQST0033]. A schema import that specifies a zero-length string as target namespace is considered to import a schema document whose target namespace (in the terminology of XSD 1.0) is absent. Such a schema import *must not* bind a namespace prefix [err:XQST0057], but it *may* set the default element/type namespace to a zero-length string (representing "no namespace"), thus enabling the definitions in the imported namespace to be referenced. If the default element/type namespace is not set to "no namespace", there is no way to reference the definitions in an imported schema that has no target namespace. It is a static error [err:XQST0058] if more than one schema import in the same Prolog specifies the same target namespace. It is a static error [err:XQST0059] if the implementation is not able to process a schema import by assembling a valid schema. It is a static error [err:XQST0012] if the set of definitions contained in all schemas imported by a Prolog do not satisfy the conditions for schema validity specified in Sections 3 and 5 of [XML Schema] Part 1--for example, each definition must be valid, complete, and unique. The following example imports a schema document, specifying both its target namespace and its location, and binding the prefix soap to the target namespace: import schema namespace soap="http://www.w3.org/2003/05/soap-envelope" at "http://www.w3.org/2003/05/soap-envelope/"; The following example imports a schema document by specifying only its target namespace, and makes it the default element/type namespace: import schema default element namespace "http://example.org/abc"; The following example imports a schema document that has no target namespace, providing a location hint, and sets the default element/type namespace to "no namespace" so that the definitions in the imported schema can be referenced: import schema default element namespace "" at "http://example.org/xyz.xsd"; The following example imports a schema and sets the default element/type namespace to "no namespace". Since no location hint is provided, it is up to the implementation to find the schema to be imported from the knowledge that there is no target namespace. import schema default element namespace "";
The WG agreed to adopt the proposal in #c1 in today's call.