This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It is permitted for context item declarations to appear in more than one module. The declaration in a library module is not allowed to set an initial value for the context item. A declaration that does not set an initial value must, by the nature of the syntax, specify "external". The semantics of "external" require the value to be supplied "by the external environment". However, the main module might contain an initializer for the context item, in which case it makes sense to use the value from that initializer, rather than reporting an error because the value was not supplied externally. (Perhaps it was intended that the "external environment" of a library module includes the main module - if so, it should say so.) The simplest fix is to change the semantics of "external" to permit the value to be supplied as a result of evaluating the initializer contained in the main module. A bolder fix would be to change the grammar so that in a library module, neither "external" nor an initial value may be specified (only a type, which is why the declaration exists in a library module).
A follow-up question. Suppose a library module has declare context item external; and the main module has declare context item := 23; Now if no external context item is supplied, it is clear that the context item in both modules should take the value 23. But what if an external context item is supplied, say 87? The rules for "declare context item external" suggest that the value should be 87, but the rules for "declare context item := 23" suggest it should be 23. But it must (I hope) be the same everywhere. Logic dictates, I think, that the value 23 wins; this reflects the interpretation that when we say the value is "supplied by the external environment" we include the case where it is supplied by the main module.
In today's telcon, we decided that library modules use the value of the context item, as determined by the main module (which provides either a value or an external declaration). Getting the wording right is going to take thought, especially in C.2 Module Dynamic Context. One possible approach: context item: Can be overwritten or augmented by prolog? => overwritten by a 4.17 Context Item Declaration in the main module
Define term "initial context item", which is used as the initial context item for evaluating the prolog and the main body of query, and is the same for all modules in a query. Dynamic Context properties for "context item": * Default initial value In a main module, none. In a library module, the context item of the main module. * Can be overwritten or augmented by implementation? overwriteable. * Can be overwritten or augmented by prolog? overwritten with a context item declaration. * Can be overwritten or augmented by expressions? overwritten during evaluation of path expressions and predicates. * Consistency rules The main module and all library modules must all have the same context item.
Context item declarations will also be modified as follows: In a library module, a context item declaration <add>must be external</add>, and specifies only the static type<add>; the context item is the context item of the main module.</add> Specifying a VarValue or VarDefaultValue for a context item declaration in a library module is a static error [err:XQST0113].
(In reply to comment #3) > * Can be overwritten or augmented by prolog? > > overwritten with a context item declaration. <add>in the main module</add>
The Working Group has adopted the resolution in comment #3, #4, and #5, modifying the consistency constraints to be less declarative (eliminate "must").
When implementing this, I added the initial context item as a separate item in appendix C2. * Component Initial context item * Default initial value none * Can be overwritten or augmented by implementation? overwriteable * Can be overwritten or augmented by prolog? overwritten by a 4.17 Context Item Declaration in the main module. * Can be overwritten or augmented by expressions? no * Consistency rules query body and prologs of all modules have the same initial context item * Component Context item * Default initial value the initial context item * Can be overwritten or augmented by implementation? no * Can be overwritten or augmented by prolog? only via the initial context item * Can be overwritten or augmented by expressions? overwritten during evaluation of path expressions and predicates * Consistency rules none