[Bug 7737] Unclear rules for schema import

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





--- Comment #1 from Michael Kay <mike@saxonica.com>  2009-09-27 21:23:15 ---
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 "";


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 27 September 2009 21:23:26 UTC