This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10291 - Test /SchemaImport/SchemaImportProlog/modules-schema-context should accept XPTY0004 as valid result
Summary: Test /SchemaImport/SchemaImportProlog/modules-schema-context should accept XP...
Status: CLOSED FIXED
Alias: None
Product: XML Query Test Suite
Classification: Unclassified
Component: XML Query Test Suite (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 major
Target Milestone: ---
Assignee: Mary Holstege
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on: 11710
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-04 07:10 UTC by Markos Zaharioudakis
Modified: 2016-04-05 14:47 UTC (History)
5 users (show)

See Also:


Attachments

Description Markos Zaharioudakis 2010-08-04 07:10:40 UTC
I think the test w3c_testsuite/XQuery/SchemaImport/SchemaImportProlog/modules-schema-context.xq should return error code XPTY0004, or at least accept this as an alternative result. This is because the item returned by the ctx:use-schema function has a type that is not in then in-scope-types of the main module, but this type is needed to evaluate the instanceof expression.
Comment 1 Mary Holstege 2010-09-07 15:18:49 UTC
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.
Comment 2 Markos Zaharioudakis 2010-09-09 04:16:27 UTC
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?
Comment 3 Markos Zaharioudakis 2010-09-09 04:23:41 UTC
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.
Comment 4 Michael Kay 2010-09-09 14:59:48 UTC
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.
Comment 5 Markos Zaharioudakis 2010-09-09 18:22:03 UTC
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 ....
Comment 6 Michael Kay 2010-09-11 20:13:26 UTC
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.
Comment 7 Mary Holstege 2010-10-19 15:35:44 UTC
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.
Comment 8 Markos Zaharioudakis 2011-01-09 20:51:08 UTC
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.
Comment 9 Michael Kay 2011-01-09 22:33:02 UTC
I have raised bug #11710 against the spec.
Comment 10 Daniela Florescu 2011-01-10 05:28:10 UTC
> 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.
Comment 11 Martin Probst 2011-01-11 10:42:09 UTC
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.
Comment 12 Mary Holstege 2011-01-11 15:45:57 UTC
MarkLogic server works like xDB in this regard: we do separate compilation and use the runtime type information.
Comment 13 Daniela Florescu 2011-01-11 18:45:13 UTC
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.
Comment 14 O'Neil Delpratt 2016-04-05 14:47:16 UTC
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.