RE: [XQuery] IBM-XQ-019: Validation context

One beneficial consequence of this proposal that may not be obvious on
first reading (I hope I've got this right) is that validation is now
carried out only as part of the process of creating or copying a node,
which means that you get rid of the problem caused by the fact that a
node before validation and the "same" node after validation are not
identical to each other.
 
Michael Kay

-----Original Message-----
From: public-qt-comments-request@w3.org
[mailto:public-qt-comments-request@w3.org] On Behalf Of Don Chamberlin
Sent: 17 February 2004 04:42
To: public-qt-comments@w3.org
Subject: [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