I think you have to start with section 5.2 which defines the allowed entry
points for validation. Section 5.2 says you can validate:

(1) against a particular global type definition. In that case it's quite
legitimate to validate an element FOO against a type definition BAR,
regardless of anything the schema might say about element FOO.

(2) against a specific element declaration. In that case section 5.2 is
explicit that validation starts with section 3.3.4 clause 1.1. So the fact
that there's a note that says 1.2 is preferred carries no weight.

(3) against nothing in particular. In this case I think it is indeed the
case that if there's an xsi:type attribute on the element, there's no
requirement that it must be consistent with any element declaration that's
present for the element. (After all, it's quite legitimate to have many
element declarations with the same element name and unrelated types.)

(Note that validation when invoked from XSLT or XQuery never uses case 3: it
always specifies either a specific type (XSLT only) or it says that you
validate against the element declaration of the element you are validating.)

Michael Kay
http://www.saxonica.com/

> -----Original Message-----
> From: xmlschema-dev-request@w... 
> [mailto:xmlschema-dev-request@w...] On Behalf Of David Maze
> Sent: 25 July 2006 21:39
> To: xmlschema-dev@w...
> Subject: Can xsi:type cause the element declaration to get ignored?
> 
> 
> 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
> 


From dmaze@u... Thu Jul 27 16:40:19 2006
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with e