(In reply to comment #0)
> XQuery specifies that the In-scope element declarations and In-scope attribute
> declarations are module scoped.
> Validation (with the 'validate' expression) validates with respect to the
> in-scope schema definitions, so the effect of a validate expression may be
> different depending on the module in which it is located.
> In its description of upd:revalidate, XQuery Update talks about revalidation,
> but doesn't specify which schema definitions this is in respect to.

It's pretty clear about which schema definitions are in scope. These are the ones that will be used.

> In the case of an updating query, I presume that this is the schema 
> definitions of the main module.

These are only in scope in the main module.

> In the case of a transform expression, I presume that this is the schema
> definitions of the module in which the transform expression is situated.

For any expression, I presume they are the schema definitions that are in scope, and those are the schema definitions of the module in which the expression is found.

Jonathan

Jonathan, I think you have missed the point of the comment, which is that upd:revalidate does not belong unambiguously to any particular module: it is performed while committing a pending update list, which might include updates generated from expressions in many different modules.

The other problem here is that we've moved to a situation where the in-scope schema for a module is almost entirely implementation-defined - so long as it includes as a minimum the components that are directly imported into the module, it can include anything else the implementor chooses. This doesn't give a high confidence in interoperability.

Here's an example.

(: library module atomic.xqm :)

module namespace example = "http://www.example.org/";
declare revalidation lax;
declare copy-namespaces preserve, no-inherit;
import schema namespace atomic="http://www.w3.org/XQueryTest" at "atomic.xsd";

declare updating function example:update()
{
  let $validated := validate strict { doc('atomic.xml') }
  return
    insert node
      <atomic:integer>1</atomic:integer>
    into $validated
};

(: main module atomic.xq :)

declare revalidation strict;
declare copy-namespaces preserve, inherit;
import module namespace example="http://www.example.org/" at "atomic.xqm";

example:update()

If I'm not mistaken, applyUpdates is called with arguments $revalidation-mode "strict" and $inherit-namespaces true.

The query may (will? should?) fail, because revalidation would use the in-scope schemas of the main module (which doesn't import the 'atomic.xsd').

The Working Group discussed this and agreed that:

1. The main module's revalidation declaration governs revalidation of the query as a whole, using the schema declarations of the  main module.

2. Revalidation declarations in other modules are used in transform expressions only.

(In reply to comment #4)

A further clarification:

> 2. Revalidation declarations in other modules are used in transform
> expressions only.

All transforms in a module with a revalidation declaration use the revalidation mode declared for that module.  The schemas used for revalidation are the schemas of that module.

I'm reopening, as I'm unable to find the agreed change in the XQuery Update 3.0 editor's draft.

I'm closing this bug again, as the decision is recorded in changes.txt and will be made in the course of time.