I'm inclined to agree. At one time our spec encouraged the interpretation that the static context of a module included the schema namespaces explicitly imported into that module, and nothing else, and I went to painful lengths to ensure that a reference to a name that wasn't explicitly imported was rejected. 

We have since repudiated that interpretation in favour of the idea that the static context contains all the schema components you happen to know about at compile time, whether explicitly imported or not. This means that XQST0036 has lost most of its original point.

(In reply to comment #1)

> We have since repudiated that interpretation in favour of the idea that the
> static context contains all the schema components you happen to know about at
> compile time, whether explicitly imported or not. 

The in-scope schema definitions still come from:

1. built-in types
2. explicit schema import
3. implementation-defined additions

Module import does not import the ISSD of the imported module. And it shouldn't - a single query should be allowed to use library modules whose definitions may conflict if merged into one ISSD, e.g. library modules for various flavors of html.

So I think the effect of the proposed change is limited: 

1. Importing such a module is not an error

2. Variables and functions can be used even if their types are unknown, because their derivation is known, and the implementation can determine whether they are allowed in a given expression.

The Working Group agreed to delete the following text (excuse the formatting loss due to lack of HTML):

<delete>
It is a static error [err:XQST0036] to import a module if the in-scope schema definitions of the importing module do not include all of the following:

An in-scope schema type for each type-name that appears:
in the type of a variable that is declared in the imported module and referenced in the importing module, OR
in a parameter-type or result-type of a function that is declared in the imported module and referenced in the importing module.
An in-scope element declaration for each element-name EN such that:
schema-element(EN) appears in the declared type of a variable in the imported module, and that variable is referenced in the importing module, OR
schema-element(EN) appears in a parameter-type or result-type of a function declared in the imported module, and that function is referenced in the importing module.
An in-scope attribute declaration for each attribute-name AN such that:
schema-attribute(AN) appears in the declared type of a variable in the imported module, and that variable is referenced in the importing module, OR
schema-attribute(AN) appears in a parameter-type or result-type of a function declared in the imported module, and that function is referenced in the importing module.
</delete>

And to modify this:

<changeme>
To illustrate the above rules, suppose that a certain schema defines a type named triangle. Suppose that a library module imports the schema, binds its target namespace to the prefix geometry, and declares a function with the following function signature: math:area($t as geometry:triangle) as xs:double. If a query wishes to use this function, it must import both the library module and the schema on which it is based. Importing the library module alone would not provide access to the definition of the type geometry:triangle used in the signature of the area function.
</changme>

The modification must illustrate the interaction of types in the two ISSDs.

The following text will be kept as is:

<keep>
The following example illustrates a module import:

import module namespace math =
  "http://example.org/math-functions";
</keep>

The following examples replace the paragraph in the <changeme/> of the previous comment:


A module import does not import schema definitions from the imported
module. In the following query, the type geometry:triangle is not
defined, even if it is known in the imported module, so the variable
declaration raises an error <errorref class="ST" code="0051"/>:

  import module namespace math = "http://example.org/math-functions";
  declare variable $t as geometry:triangle := geometry:make-triangle();

  $t

Without the type declaration for the variable, the variable
declaration succeeds:

  import module namespace math = "http://example.org/math-functions";
  declare variable $t := geometry:make-triangle();

  $t

Importing the schema that defines the type of the variable, the
variable declaration succeeds:

  import schema namespace geo = "http://example.org/math-schema-declarations";
  import module namespace math = "http://example.org/math-functions";
  declare variable $t as geometry:triangle := geometry:make-triangle();

  $t

In meeting  #468, the Working Group agreed to adopt comment #3 as our resolution of this bug.