Let's say you have a hypothetical schema like:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="element" type="xs:integer"/>
</xs:schema>

And an input

<element xsi:type="xs:string"
         xmlns:xs="http://www.w3.org/2001/XMLSchema"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>

I want to determine that element's [validity] in the PSVI, so I look at 
cvc-assess-elt.  (For bonus points, we'll let the processor specify the 
element declaration.)  Item 1 says that one of 1.1 or 1.2 must be valid; I 
decide to look at 1.2, since the note below says that 1.2 takes 
precedence.  In cvc-assess-elt 1.2.1.2 I see that I have an xsi:type 
attribute, and there isn't a processor-stipulated type definition, so the 
local type definition is the type for xs:string.  Now I have a type 
definition, so I apply cvc-assess-elt 1.2.2, which says to ask cvc-type, 
which says the element is valid if it's a valid xs:string, which it is. 
Thus, cvc-assess-elt 1.2 is true, so cvc-assess-elt 1 is true, and thus 
the element has been strictly assessed, and since nothing is known to be 
invalid the element's [validity] is valid.

I think this clearly isn't what the schema spec intends.  If we had 
followed the path of believing the processor-specified element declaration 
and going into cvc-elt, we'd hit cvc-elt 4, which specifies much the same 
things about xsi:type as cvc-assess-elt 1.2.1.2, except that there we'd 
conclude that xs:string isn't derived frnom xs:integer and decide the 
element's [validity] is invalid.  That is, it seems to me like if you can 
determine an element declaration for the element you're validating then 
you must honor it; I think that would imply adding a clause to 
cvc-assess-elt 1.2 that stated that no element declaration is found as per 
cvc-assess-elt 1.1.1.

David Maze
Engineer, SOA Appliance Group, IBM Application Integration Middleware
One Alewife Center, 4th Floor, Cambridge, MA 02140
Phone: 617-864-0455 x231 Fax: 617-864-0458