[XQuery] IBM-XQ-019: Validation context

(IBM-XQ-019) Section 3.7.1.5, Type of a Constructed Element: This section 
says that a direct element constructor adds the name of the constructed 
element to the validation context for nested expressions. Does this rule 
still apply if the direct element constructor has an xsi:type attribute? 
How can validation context (a static property) be affected by the value of 
an xsi:type attribute (which can be dynamic)?

Similarly, in Section 3.7.3.1, Computed Element Constructors: If the name 
of the constructed element is computed by an expression (which, after all, 
is the reason for having a computed element constructor), the validation 
context for nested expressions is set to "global". This seems likely to 
cause problems. Suppose that I use a computed element constructor to 
construct an element named Address, with a nested element named Zipcode. 
If Address is a computed name, the validation context for the Zipcode 
element will be "global". But it's likely that the Zipcode element is not 
defined globally, but only within an Address.

Because of examples like this, I am increasingly skeptical of the concept 
of "validation context". I do not believe that it is well understood. I 
think we would be well advised to stop trying to validate things that do 
not have top-level schema definitions, at least in XQuery Version 1. 
Deferring this complex and poorly understood feature until after XQuery 
Version 1 would provide us with practical experience that might lead to a 
more robust design if this feature is found to be needed in a later 
version. It would also allow us to focus our efforts on more important 
issues such as defining an update language.

My specific proposal is as follows:

(a) Eliminate "validation context" from the Static Context.

(b) Eliminate ValidationContext (formerly called SchemaContext) from the 
grammar.

(c) Replace Section 3.7.1.5, Type of a Constructed Element, with a new 
section based closely on 
http://www.w3.org/TR/xslt20/#validating-constructed-nodes as suggested by 
Michael Kay. This will bring XQuery into alignment with XSLT 2.0. It will 
also resolve all the questions raised in this comment, including how to 
deal with xsi:type attributes. The text suggested by Mike is Section 
19.2.1 of the XSLT 2.0 document, entitled "Validating Constructed Elements 
and Attributes". It can be inserted into the XQuery document with minor 
editing, such as replacing "validation attribute" with "validation mode", 
replacing "synthetic schema document" with "in-scope schema definitions", 
and deleting XSLT-specific references such as "xsl:copy-of".

(d) Replace Section 3.14, Validate Expressions, with a new section based 
closely on Sections 19.2.1 and 19.2.2 of the XSLT 2.0 document, which 
define validation for element and document nodes, respectively.

The result of this proposal will be to simplify XQuery, bring it into 
alignment with XSLT 2.0, resolve the questions raised in this comment, and 
dispose of Action Item XQUERY-162-03.

A related action, which I do not believe to be required by this proposal 
but which would certainly be consistent with it, would be to eliminate 
SchemaContextPath from the SequenceType syntax, cleaning up another 
complex and poorly understood part of the language.

--Don Chamberlin