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

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.

[This re-send of this message includes the promised attachments:
a sample schema, a test document, and HTML transforms of the 
PSVI dumps for both Xerces J and XSV which make it slightly 
easier to see what is valid and what is invalid.  The full 
XML of the PSVI dumps is not attached; those interested can
either generate it themselves or contact me and I'll send it
privately.]


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


<!--* 
<!DOCTYPE xsd:schema 
  PUBLIC "-//W3C//DTD XMLSCHEMA 200105//EN"
         "http://www.w3.org/2001/XMLSchema.dtd" [
<!ENTITY % schemaAttrs "
  xmlns:this CDATA #IMPLIED
  xmlns:xsd  CDATA #IMPLIED"
>
<!ENTITY % p "xsd:">
<!ENTITY % s ":xsd">
<!ENTITY % html-for-documentation SYSTEM
  "/SGML/Public/W3C/xhtml-divs.dtd">
%html-for-documentation;

]>
*-->
<xsd:schema 
 xmlns:xsd ="http://www.w3.org/2001/XMLSchema" 
 xmlns:this="http://example.com/XMLSchema/svae" 
 targetNamespace="http://example.com/XMLSchema/svae"
 elementFormDefault="qualified" 
 >
 <xsd:annotation>
  <xsd:documentation>
   <div xmlns="http://www.w3.org/1999/xhtml">
    <div>
     <h1>Intro</h1>
     <p>Sample schema for use in illustrating processor behavior
      when there is both an element declaration and an xsi:type
      attribute and thus clauses 1.1 and 1.2 of Schema-Validity
      Assessment (Element) both apply.</p>
    </div>

    <div>
     <h1>Cases</h1>
     <p>There are several cases which may be worth distinguishing;
      it will be interesting and surprising if any processors
      treat them differently:</p>
     <ul>
      <li>The processor has stipulated an element declaration (e.g.
       as a command-line option).</li>
      <li>The element declaration was found for an element which
       matched a lax (or strict) wildcard.</li>
      <li>The element declaration is the context-determined
       declaration for the element.</li>
     </ul>
     <p>There are two ways I'll try to elicit telltale behavior
      from the processors:</p>
     <ul>
      <li>Specify an xsi:type value which is not derived from
       the declared type.  If the element is validated against the
       element declaration, this will raise an error; if SVA(E)
       clause 1.2 takes priority, the element declaration will be
       passed over and no error will be raised.</li>
      <li>Nil out the element, or specify xsi:nil='false'.  If
       the element declaration is passed over, this should have no
       effect even if the element is not nillable.</li>
     </ul>
    </div>

    <div>
     <h1>Types and elements</h1>
     <p>We define three types to test the type-derivation error:</p>
     <ul>
      <li>T1 allows a sequence of 'e' elements.</li>
      <li>T2 is derived from T1.</li>
      <li>T3 is not derived from T1.</li>
     </ul>
     <p>We define two elements, both of type T1, one nillable
      and one not.</p>
     <p>Additionally, we define a couple of elements to contain
      strictly validated and laxly validated wildcards.</p>
    </div>
   </div>
  </xsd:documentation>
  <xsd:appinfo>
  </xsd:appinfo>
 </xsd:annotation>

 <xsd:complexType name="T1">
  <xsd:sequence minOccurs="0" maxOccurs="unbounded">
   <xsd:element ref="this:e"/>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:complexType name="T2">
  <xsd:complexContent>
   <xsd:restriction base="this:T1">
    <xsd:sequence minOccurs="1" maxOccurs="10">
     <xsd:element ref="this:e"/>
    </xsd:sequence>
   </xsd:restriction>
  </xsd:complexContent>
 </xsd:complexType>
 <xsd:complexType name="T3">
  <xsd:sequence minOccurs="1" maxOccurs="unbounded">
   <xsd:element ref="this:e"/>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:complexType name="dcc">
  <xsd:choice minOccurs="0" maxOccurs="unbounded">
   <xsd:element ref="this:e"/>
   <xsd:element ref="this:e_nil"/>
   <xsd:element ref="this:e_non"/>
   <xsd:element ref="this:strict"/>
   <xsd:element ref="this:lax"/>
   <xsd:element ref="this:skip"/>
  </xsd:choice>
 </xsd:complexType>

 <xsd:element name="doc" type="this:dcc"/>
 <xsd:element name="e_nil" nillable="true" type="this:T1"/>
 <xsd:element name="e_non" nillable="false" type="this:T1"/>
 <xsd:element name="e"/>

 <xsd:element name="strict">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:any processContents="strict" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:element name="lax">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
 <xsd:element name="skip">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>

</xsd:schema>
<!-- Keep this comment at the end of the file
Local variables: 
mode: xml 
sgml-default-dtd-file:nil 
sgml-omittag:t 
sgml-shorttag:t 
End:
-->