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 23488 - context item in module
Summary: context item in module
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Working drafts
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: O'Neil Delpratt
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-14 12:31 UTC by Benito van der Zander
Modified: 2014-04-01 21:35 UTC (History)
2 users (show)

See Also:


Attachments

Description Benito van der Zander 2013-10-14 12:31:23 UTC
The test cbcl-module-004 with XQ10+ dependency assumes an imported module can access the context item of the query it is imported in.

But this is only required in the XQuery 3 standard, in the XQuery 1 standard it says about modules "The context item, position, and size in the dynamic context of the initializing expression have initial values as described in C.2 Dynamic Context Components." where it says "Default initial value = none", it should be undefined. 

So the test should have a XQ30+ dependency
Comment 1 Michael Kay 2013-10-14 14:37:40 UTC
Personal response/analysis:

I believe the situation is as follows:

(a) Neither XQuery 1.0 nor XQuery 3.0 requires a processor to provide a mechanism to set the initial context item either for a main module or for a library module.

(b) XQuery 3.0 requires the initial context item for all modules to be the same; XQuery 1.0 does not.

(c) The test suite documentation says that role="." sets the initial context item; it should perhaps say more clearly that it does so for all modules.

(d) The test suite documentation says that an implementation that does not provide the ability to inialize any part of the dynamic context as requested by the test metadata should not run the test, and should report a result of "notRun".

So I don't believe this test is dependent on XQ 3.0. It *is* dependent on the ability to set the context item for library modules, but the documentation makes it clear how the test driver should behave in the case of an implementation that is not able to do that.
Comment 2 Benito van der Zander 2013-10-16 12:11:16 UTC
I think this test is supposed to test, if the context item of the main query is  shared to all imported modules.

Otherwise, if the test suite sets the context item directly for all modules, this test only tests the capabilities of the test suite, and there is no test left testing if it is shared to the modules in a real application without the test suite...
Comment 3 Michael Kay 2013-10-16 13:18:31 UTC
If your query API allows you to set the context item differently for different modules, then that allows something that XQuery 3.0 doesn't allow. There's no way the test suite can test for the absence of such extensions to the spec.
Comment 4 Benito van der Zander 2013-10-16 22:43:17 UTC
But if the test suite requirements say the test harness should not set the context item for any module, and only set the context item of the main query, it would test this.
Comment 5 Michael Kay 2013-10-16 23:32:23 UTC
I think we're talking at cross-purposes. In XQuery 3.0 it is made clear that there is not one context item per module, there is just one context item for the query as a whole. So I don't understand what you mean when you talk of setting the context item for a particular module - there is no such thing.
Comment 6 Benito van der Zander 2013-10-17 00:03:10 UTC
> In XQuery 3.0 it is made clear that there is not one context item per module

I only consider XQuery 1 (after all the test does not have a XQ3 dependency)

There it says:

"Each module has its own static context. " and "During evaluation of a function body, the static context and dynamic context for expression evaluation are defined by the module in which the function is declared, which is not necessarily the same as the module in which the function is called." and "[Definition: If a variable declaration includes an expression, the expression is called an initializing expression.] The initializing expression for a given variable must be evaluated before the evaluation of any expression that references the variable. The static context for an initializing expression includes all functions that are declared or imported anywhere in the Prolog, but it includes only those variables and namespaces that are declared or imported earlier in the Prolog than the variable that is being initialized. The context item, position, and size in the dynamic context of the initializing expression have initial values as described in C.2 Dynamic Context Components." 

So you have one static context for every module, and during function evaluation one dynamic context for every module, and you need to create a dynamic context for the evaluation of the initializing variables of the module, so the logical conclusion is that you also  have one dynamic context for every module during variable evaluation. And the context item in that context could then be called the context item of the module.
Comment 7 Michael Kay 2013-10-17 08:14:02 UTC
OK, I'm assigning it to the chair, which is a way of saying it needs WG discussion/decision.

I think the WG has a choice:

(a) decide that the XQuery 1.0 specification needs clarification, and that XQuery 1.0 implementations are expected to do what XQuery 3.0 says, namely, to have a single context item for initializing all variable declarations regardless what module they appear in, or

(b) decide that XQuery 1.0 leaves this question implementation-defined, in which case the situation becomes impossible to test, and this test case should not apply to XQuery 1.0.

Please be aware that resolving XQuery 1.0 issues is not high on the WG's list of priorities right now, so this could take a while to get meeting time allocated.
Comment 8 O'Neil Delpratt 2014-04-01 21:35:36 UTC
(In reply to Michael Kay from comment #7)

> 
> (b) decide that XQuery 1.0 leaves this question implementation-defined, in
> which case the situation becomes impossible to test, and this test case
> should not apply to XQuery 1.0.

The WG has decided at the telcon. #566 that option (b) is more appropriate. This means that the test case will have a dependency on XQ30+.

Thanks Benito for raising the issue.