possible error in priority rule for Schema-Validity Assessment (Element)

This message has four parts: the description of what I believe is a
problem in the XML Schema spec, the description of an example that
exercises the rule in question, the description of behavior of two
current processors, and a proposed correction.


1 PROBLEM

I believe there is an error in the prose immediately following the
validation rule Schema-Validity Assessment (Element) in Structures
3.3.4.  It reads in part:

    Note: In general if clause 1.1 above holds clause 1.2 does not,
    and vice versa. When an xsi:type [attribute] is involved, however,
    clause 1.2 takes precedence, as is made clear in Element Locally
    Valid (Element) (&sec;3.3.4).

I believe that if we are to validate an element against an element
declaration, whether because the element declaration was stipulated by
the processor as part of starting validation, or because the element
declaration is the context-determined declaration, then validation
should assess the element against that element declaration, not
against the type definition named in the xsi:type attribute.  In
particular:

  - Nillability, value constraints, and the type derivation relation
    should be checked against the element declaration *before* the
    type definition named in the xsi:type attribute is consulted.
    The rules in Element Locally Valid (Element) will ultimately
    cause the validation of the element against that type; there is
    no point in short-circuiting the validation against the element
    declaration.

  - When the element has a context-determined declaration of 'skip',
    an xsi:type attribute on the element must not be allowed to
    cause validation:  the 'skip' should have priority, otherwise
    the 'skip' keyword has lost its purpose.


2 EXAMPLE 

An example schema and test document are attached to this email.  The
test document uses elements with xsi:type and xsi:nil attributes in
three contexts (with a context-determined declaration, matching a lax
wildcard, and matching a strict wildcard) where the Schema-Validity
Assessment (Element) rule should be applied.

All elements are legal instances of the type named by xsi:type.  Some
of them however are not valid against their declared type, either
because they name a type (T3) in xsi:type which is not derived from
their declared type (T1), or because they are nilled out when the
element is declared non-nillable.

If clause 1.2 takes precedence over clause 1.1, as the text of the
spec says it does, then the elements should all be validated only
against the type definition named in xsi:type and no errors based on
the element declaration should be raised.  


3 TEST RESULTS

Both xsv and Xerces J raise errors against the elements which are
invalid against their element declarations.  That is, they seem to
agree with my analysis that when both an element declaration and a
type definition are given, the element should be validated against the
element declaration.  

Xerces J raises errors both on the examples which specify T3 as the
value of xsi:type and on the examples which specify a value for
xsi:nil despite being declared non-nillable.  XSV raises errors only
on the former; I am not sure whether there is simply a bug in XSV's
failure to raise a cvc-elt.3.1 error, or whether the authors of XSV
disagree with the authors of Xerces J and with me that the instances
in the test document of element e_non with xsi:nil attributes should
be flagged as invalid.


4 PROPOSED CHANGE

Correct the text to read

    Note: In general if clause 1.1 above holds clause 1.2 does not,
    and vice versa. When both may apply, e.g. when an xsi:type
    [attribute] is specified on an element for which an element
    declaration is also available as described in clause 1.1, then
    clause 1.1 takes takes precedence. The type named by the xsi:type
    [attribute] will be used in validation if appropriate, as is made
    clear in Element Locally Valid (Element) (&sec;3.3.4).


--C. M. Sperberg-McQueen