If the context item is defined for global variables, then this also raises the question as to whether it should be defined for global variables in imported modules.  The specification doesn't seem to help with this either.

At least several implementations do define the initial context before the prolog is executed, and our whole discussion of expression evaluation presumes the initial context.

I propose we make this explicit as follows:

<old>
[Definition: The dynamic evaluation phase is the phase during which the value of an expression is computed.] It occurs after completion of the static analysis phase.
</old>

<new>
[Definition: The dynamic evaluation phase is the phase during which the value of an expression is computed.] It occurs after completion of the static analysis phase and after the initial context has been created. The dynamic evaluation phase includes evaluation of dynamic expressions in the prolog, followed by evaluation of the query body.
</new>

(In reply to comment #2)
> [Definition: The dynamic evaluation phase is the phase during which the 
> value of an expression is computed.]

I'm thinking that "an expression" should be "a query".

> It occurs after completion of the static analysis phase 
> and after the initial context has been created.

It might be better to say "initial dynamic context", since the initial static context would have been created before the static analysis phase.

(Also, it's somewhat incorrect to refer to *the* initial context, since there could be more than one [e.g., one per module]. The description of the static analysis phase has the same problem. But fixing it will probably wait until 1.1.)

> The dynamic evaluation phase includes evaluation of dynamic expressions 
> in the prolog, followed by evaluation of the query body.

There's no such thing as "dynamic expressions". You might mean "initializing expressions".

I think that sentence would fit better as the last or second-last sentence of para 3 in 2.2.3.2.

Also, I think we're missing a sentence such as:
    If the Module Feature is supported, the dynamic context is extended with
    variable values and function implementations from imported modules.
(i.e., the dynamic evaluation phase is not just concerned with the main module, it also involves processing the prologs of library modules). But maybe that should wait for 1.1 as well.

My initial comment was: "There seems to be no statement in XQuery that says whether the context item, position, and size are defined when referenced within the initializing expression of a global variable."

It seems that the WG has decided that these are defined, and that they are the same as the context item, position, and size in the expression that forms the QueryBody in the main module. It seems to me that the place to say that is in para 4 of 4.14 Variable Declaration. After "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." add "The dynamic context for an initializing expression is the same as the dynamic context for the QueryBody in the main module, except that Variable Values and Function Implementations are populated only for those variables and functions that are within the static context of the expression".

(In reply to comment #4)
> My initial comment was: "There seems to be no statement in XQuery that says
> whether the context item, position, and size are defined when referenced
> within the initializing expression of a global variable."
> 
> It seems that the WG has decided that these are defined,

Not necessarily. If the implementation leaves them undefined in the initial dynamic context, and nothing else in the prolog causes them to be defined in the dynamic context that's in effect at the point the reference is made, then they would be undefined.

> and that they are the same as the context item, position, and size in
> the expression that forms the QueryBody in the main module.

Not necessarily that either, since a library module might get an initial dynamic context that differs from that of the main module. (E.g., I can imagine an implementation saying that the initial focus is undefined for a library module, but set via invocation parameters for the main module.)

It *is* normally true, I think, that the focus for the QueryBody in the main module is the same as the focus for initializing expressions in the main module, which is also the same as the focus in the initial dynamic context for the main module. However,

(a) the focus for an initializing expression isn't always the same as the focus for expressions *within* the initializing expression; and

(b) an implementation is allowed (as far as I can tell) to define an option declaration that sets the focus, in which case the initial focus, the focus at an initializing expression, and the focus at the QueryBody might all be different.


> "... Variable Values and Function Implementations are populated only for those
> variables and functions that are within the static context of the expression".

Note that the definition of the 'variable values' dynamic component already states that (for a given expression) it contains the same set of variables as the 'in-scope variables' static component. The 'function implementations' dynamic component doesn't quite make the corresponding statement with respect to the 'function signatures' static component; perhaps it should. Anyway, appendix C.2 requires static/dynamic consistency for both variables and functions.

> MK: It seems that the WG has decided that these are defined,
> MD: Not necessarily. 

I don't actually know what the WG decided - I've only got the minutes to go by. One option was clearly that the dynamic context in a variable initializer should be the same as that in a function body - explicitly undefined[*]. I got the impression that the WG decided firmly against that. That's really what I meant by saying the WG had decided that the focus is "defined".

If the focus is not explicitly undefined, then I think it should be the same as for the QueryBody in the main module. I can't see any sense in making it different in different modules - it would complicate the API immensely. (I could see some logic in saying that the focus is explicitly undefined for variable initializers in library modules: that could prevent some subtle bugs.) 

This means of course that if the focus is undefined in the QueryBody then it is undefined in variable initializers. Also, of course, I'm talking about the focus for the variable initializer as a whole - it can change within subexpressions in the usual way.

Option declarations are allowed to do anything they like; you can define an option declaration that makes 2+2=5. So I don't think we need to worry too much about that case.

Incidentally, in XSLT the context item in a global variable declaration is the node at the root of the tree that contains the initial context item of the transformation. A curious rule: IIRC we did it for compatibility with an MSXML behaviour that had been emulated by several other XSLT 1.0 processors.

[*] for avoidance of doubt, by "explicitly undefined" I mean "defined to have no value", whereas "undefined" could be read as "not defined by this specification".

Mike Kay wrote:

[quote]If the focus is not explicitly undefined, then I think it should be the same as
for the QueryBody in the main module. I can't see any sense in making it
different in different modules - it would complicate the API immensely. (I
could see some logic in saying that the focus is explicitly undefined for
variable initializers in library modules: that could prevent some subtle bugs.) [/quote]

I believe this was the sense of the discussion - the focus is the same as for the QueryBody in the main module. Although it would make sense for the focus to be undefined, at least some implementations currently define it, and at least some users are taking advantage of this to set variables using the initial focus.

Jonathan

I believe the best solution is to add both the statements Mike Kay asked for and an amended version of my changes to the description of the dynamic evaluation phase.

In http://www.w3.org/TR/xquery/#id-dynamic-evaluation:

<old>
[Definition: The dynamic evaluation phase is the phase during which the value
of an expression is computed.] It occurs after completion of the static
analysis phase.
</old>

<new>
[Definition: The dynamic evaluation phase is the phase during which the value
of an expression is computed.] It occurs after completion of the static
analysis phase and after the initial dynamic context has been created. The dynamic evaluation phase includes evaluation of the prolog, followed by evaluation of the query body.
</new>

In http://www.w3.org/TR/xquery/#id-variable-declarations

After "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." 

Add "The dynamic context for an initializing expression is the same as the dynamic context for the QueryBody in the main module, except that Variable Values and Function Implementations are populated only for those variables and functions that are within the static context of the expression".

(In reply to comment #8)
> 
> In http://www.w3.org/TR/xquery/#id-dynamic-evaluation:
> 
> <old>
> [Definition: The dynamic evaluation phase is the phase during which the value
> of an expression is computed.] It occurs after completion of the static
> analysis phase.
> </old>
> 
> <new>
> [Definition: The dynamic evaluation phase is the phase during which the value
> of an expression is computed.] It occurs after completion of the static
> analysis phase and after the initial dynamic context has been created. The
> dynamic evaluation phase includes evaluation of the prolog, followed by
> evaluation of the query body.
> </new>

Upon reflection, I'd be inclined to say that creation of the initial dynamic context occurs *within* the dynamic evaluation phase, rather than before it. Note that step DQ3, in which the dynamic context "draws information from the external environment" is apparently part of the dynamic evaluation phase, and that (for comparison) the static environment is initialized as part of the static analysis phase. 

Thus, rather than replacing the existing <old> text we could just add the following sentence to it: 
    The dynamic evaluation phase includes creation of the
    initial dynamic context, followed by evaluation of
    the prolog, followed by evaluation of the query body.


> In http://www.w3.org/TR/xquery/#id-variable-declarations
> 
> After "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." 
> 
> Add "The dynamic context for an initializing expression is the same as the
> dynamic context for the QueryBody in the main module, except that Variable
> Values and Function Implementations are populated only for those variables and
> functions that are within the static context of the expression".

This is incorrect. For an initializing expression X in a library module L, the dynamic context of the QueryBody doesn't even necessarily *have* definitions for the variables and functions in the static context of X. And, where it does, those definitions may differ from the ones established by the prolog of L.

Perhaps it would suffice to note that, in the dynamic context for an initializing expression, the focus is the same as that of the initial dynamic context of the module containing the initializing expression.

The Query Working Group discussed this bug report on 18 March 2008, and resolved the issue as follows: In XQuery Section 4.14 (Variable Declaration), add the following sentence at the end of the third paragraph: "The context item, position, and size in the dynamic context of the initializing expression have initial values as described in appendix C."
-- Don Chamberlin (for the Query Working Group)