10291 2010-08-04 07:10:40 +0000 Test /SchemaImport/SchemaImportProlog/modules-schema-context should accept XPTY0004 as valid result 2016-04-05 14:47:39 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite unspecified PC Linux CLOSED FIXED P2 major --- 11710 1 markos_za holstege chillery-w3cbugs dflorescu mike oneil Probst_Martin public-qt-comments oldest_to_newest 37224 0 markos_za 2010-08-04 07:10:40 +0000 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. 38516 1 holstege 2010-09-07 15:18:49 +0000 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. 38725 2 markos_za 2010-09-09 04:16:27 +0000 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? 38726 3 markos_za 2010-09-09 04:23:41 +0000 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. 38750 4 mike 2010-09-09 14:59:48 +0000 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. 38756 5 markos_za 2010-09-09 18:22:03 +0000 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 .... 38890 6 mike 2010-09-11 20:13:26 +0000 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. 41559 7 holstege 2010-10-19 15:35:44 +0000 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. 43972 8 markos_za 2011-01-09 20:51:08 +0000 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. 43975 9 mike 2011-01-09 22:33:02 +0000 I have raised bug #11710 against the spec. 43979 10 dflorescu 2011-01-10 05:28:10 +0000 > 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. 44133 11 Probst_Martin 2011-01-11 10:42:09 +0000 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. 44149 12 holstege 2011-01-11 15:45:57 +0000 MarkLogic server works like xDB in this regard: we do separate compilation and use the runtime type information. 44178 13 dflorescu 2011-01-11 18:45:13 +0000 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. 125722 14 oneil 2016-04-05 14:47:16 +0000 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.