This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specification for upd:revalidate() describes the effect in terms of the revalidation mode "in the static context". But which static context? For a query that does updates at the top level, it should presumably be the revalidation mode defined in the main query module. For updates done within a transform (copy-modify) expression, it should presumably be the revalidation mode defined in the module containing the transform expression. (The description of revalidation mode says its scope is global. But it doesn't say what this means. Does it mean it's an error to define different values in different modules? If so, what error?)
I think the spec is reasonably clear on this. upd:revalidate() is invoked only by upd:applyUpdates, which in turn is invoked only by a top-level expression or by a transform expression. As usual, the processing of an expression is governed by the static context that is defined for that expression. We probably don't want to raise an error if an imported module has a different revalidation mode from the importing module. This would make it difficult to write modules that can be called from different environments. Therefore we should change "global" to "module" in the description of revalidation mode in Section 2.3 (Extensions to the Static Context).
Michael, On 22 Jan 2008, the Query Working Group considered this bug report and decided to change the scope of Revalidation Mode from "global" to "module" as suggested in Comment #1. If you are satisfied with this resolution, please change the status of this bug report to Closed. --Don Chamberlin (for the Query Working Group)
I'm not convinced that the proposed change is sufficient to make it clear that (as Don states in comment #1) (a) when we're dealing with a "top-level" updating query, the static context that applies is the static context of the top-level module (b) when we're dealing with updates within a transform expression, the static context that applies is the static context of the module containing the transform expression. Normally functions don't inherit the context of their caller. Don is suggesting, in effect, that it is "reasonably clear" that upd:revalidate() inherits the context of upd:applyUpdates(), and that upd:applyUpdates() in turn inherits the context of either the top-level expression or the transform expression. Well, it may be clear to the author of the spec, but I don't think that necessarily makes it clear to the reader.
On 05 Feb 2008 the Query Working Group reconsidered this issue and approved the following resolution which was proposed by Michael Kay: 1. Give the functions upd:applyUpdates() and upd:revalidate() an extra argument: $reval as revalidation-mode explaining that this takes the value strict, lax, or skip 2. Change clause 5 of 3.2.2 upd:applyUpdates to say: For each document or element node $top that was marked for revalidation by one of the earlier steps, upd:revalidate($top, $reval) is invoked. 3. In 3.2.3 upd:revalidate, change references to "revalidation mode [in the static context]" to refer to $reval 4. Change clause 3 of 2.4.5 transform to start "Let $reval be the value of the revalidation mode in the static context of the transform expression. The following update operation is invoked: upd:applyUpdates($pul, $reval). 5. In 2.1 processing model, change rule 3. Replace "If the outermost expression in a query returns a pending update list, upd:applyUpdates is implicitly applied to this pending update list. " by "If the outermost expression in a query returns a pending update list, upd:applyUpdates is implicitly called, supplying as arguments (a) the pending update list, and (b) the value of the revalidation mode in the static context of the main query module.