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)