We believe this comment is invalid.  The main module needs xs:int to be in the in scope schema types, which it is.  It also needs to use information that the dynamic type is derived from xs:int, which is available because the schema was imported into the imported module.  Since it is often the case that an imported module would import a schema that is not imported into the main module as well, throwing a type error in such circumstances is not useful.

I am sorry, but comment #1 does not make sense. In particular, the sentence "It also needs to use information that the dynamic type is derived from xs:int, which is available because the schema was imported into the imported module." is wrong (or I am missing something). The main module does not know anything about the dynamic (user-defined) type, because that type is not among its in-scope schema types. Furthermore, for each item, the XDM stores the name of the item's type and nothing else.

If you still think that comment #1 is correct, can you please point me to the specific part(s) of the W3C spec(s) that support this claim?

I forgot to say that XQuery 1.1 allows for some implementation-defined way by which the main module acquires knowledge of type derivation, even if the type is not in its in-scope type definitions. However, if an implementation does not provide any such ways, then XPTY0004 should be the correct result for this test. So, both the current result as well as XPTY0004 should be acceptable alternatives for this test.

I agree with Mary: there seems to be a problem here.

One solution might be to state that the dynamic context (for all expressions in the query) contains the union of all schema components in the static contexts of all modules of the query, and that run-time instance-of tests have access to this extended set of schema components.

We all agree there is a problem. I understand that from a user's point of view, throwing an error in a situation like this is not good. But, given the current spec, I don't see how an error can be avoided without any implementation-defined extensions. 

What is proposed in comment #4 is a modification to the spec, right? In this case, why extend the dynamic context only? Why not do the same for the static context as well? This would allow more query optimizations during compile time.

Another possible solution is to provide for public and private schema imports. If a module A imports a schema "publicly", that schema become visible to any other module that imports A. Just a thought ....

Yes, comment #4 is proposing a modification (or clarification) to the spec.

The reason for not proposing any change to the static context rules is that XQuery is designed to allow modules to be independently compiled, so we minimize the amount that the compiler needs to know about the query as a whole when compiling a single module. (The fact that XSLT has a global static context is the main reason that XSLT stylesheet modules cannot be separately compiled.) But this argument doesn't apply at run-time; I think it's reasonable to assume that at run-time, the processor has access to (at least) the union of the schema components in the static contexts of all modules. Alternatively, we might define that all types used during validation of instance documents are "known" types for the purpose of section 2.5.4 - so if you are looking at a node with a particular type annotation, that type is by definition a "known" type.

I agree that contradicts what we currently say "An unknown schema type might be encountered, for example, if a source document has been validated using a schema that was not imported into the static context." But I think this test case demonstrates that this isn't viable - it makes it impossible to write interoperable queries. A function is always allowed to return a value that belongs to a subtype of the type appearing in the function signature, and if there is no guarantee that the caller of the function (who only knows about the declared type) can handle this value, we lose substitutability and this is so fundamental to the language design that it's not a viable option.

The WG agrees that the specification lacks clarity on this point and intends
to clarify in a future version.  The intended behaviour is that an error not
be permitted in this case for usability and interoperability reasons.

I am sorry, but I am not happy with the status-quo regarding this bug. Basically,I have not seen any progress in amending the spec to resolve this very important issue. Until this is done, I would like to ask that either this test is removed from XQTS or XPTY0004 is accepted as an alternate result. Otherwise, how can any implementation be conformant with the spec as it is today.

I have raised bug #11710 against the spec.

> The reason for not proposing any change to the static context rules is that
> XQuery is designed to allow modules to be independently compiled, 

Mike,

for as much I wish your statement would be true: well, no, XQuery is not currently
designed for independent compilation of modules.

It hasn't been an official requirement, and, unfortunately, this goal hasn't be pursued
during the design of XQuery.

as a result, this is not true now. Modules cannot be compiled independently in XQuery.
 Which is really bad.

Maybe we do something wrong, but xDB actually compiles modules independently - imported modules have no knowledge of schemata imported by the parent module, and the parent module has no knowledge of schemata imported by the imported modules.

We actually do the subtype check based on the runtime type, which is what MKay is proposing, and it works. I'm not aware of any other limitation in this area - Dana, could you give specific examples of what else doesn't work?

@Markos: 

"What is proposed in comment #4 is a modification to the spec, right? In this
case, why extend the dynamic context only? Why not do the same for the static
context as well? This would allow more query optimizations during compile time."

There is nothing keeping you from doing that behind the scenes, as long as the result it gives is identical to the specified behaviour.

MarkLogic server works like xDB in this regard: we do separate compilation and use the runtime type information.

In response to comment #11 and #12. Sorry, I should have been more 
clear. XQuery **3.0** as it stands today doesn't allow independent compilation.
I was not talking about XQuery 1.0.

See bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=11352
for an example. This was the original problem that I raised then, and that
triggered the long discussion about the semantics of non-determinism.
I did not bring up again the original problem of lack of independent compilation 
because apparently we don't have yet an agreement on what the spec should be
 in this area.

So I presume that your query engines don't have a problem (yet) because 
you did not implement yet that version of  XQuery 3.0, with %nondeterministic. 
Zorba does, and hence  the problem that I raised.

Given the resolution of the WG in comment #7 and the spec change made in bug #11710 (refered in comment #9) I am closing this bug.