RE: Can xsi:type cause the element declaration to get ignored?

...but my original argument was that, if there's an xsi:type attribute, 
the note in Schema-Validity Assessment (Element) says that cvc-assess-elt 
1.2 takes precedence, which says you get to jump straight to Element 
Locally Valid (Type) without checking little details like that based on 
the element declaration.

I think the correct behavior is obvious, and I'm largely nitpicking here 
(or trying to follow the flow of the spec and failing).  The case that's a 
little less clear to me deals with wildcards: if you have a wildcard with 
processContents="strict" and hit this sort of case where the 
.context-determined declaration. is mustFind, and a global declaration 
matches, but there's a conflicting xsi:type attribute, which one is "more 
right"?  What if processContents="lax"?  Reading this section yet again, I 
think if processContents="skip", then cvc-assess-elt 1.1 can't trip, but 
cvc-assess-elt 1.2 could given an xsi:type attribute.  Otherwise, it's 
consistent to believe cvc-assess-elt 1.1 over 1.2 and do validation 
against an element declaration if you can find one.

Following this line of reasoning further, the note's appeal to Element 
Locally Valid (Element) doesn't actually make a whole lot of sense; it's 
more like, if you have an element declaration which names a type, and an 
xsi:type attribute, the xsi:type will ultimately win as per cvc-elt 4.3 
(provided it's a type derived from the element's type).  Which is similar 
to what the note says, but "the xsi:type eventually wins but you still 
need to check the element declaration" is different from "the xsi:type 
trumps the element declaration", which is what the note seems to imply.

Thanks (and sorry for rambling a little in schema-ese),

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



"Michael Kay" <mike@saxonica.com> 
07/27/06 01:07 PM

To
David Maze/Cambridge/IBM@IBMUS, <xmlschema-dev@w3.org>
cc

Subject
RE: Can xsi:type cause the element declaration to get ignored?






I think that this is covered by 3.3.4 Validation Rule: Element Locally 
Valid (Element) clause 4.3, which says that the xsi:type must be validly 
derived from the declared type of the element.
 
Michael Kay
http://www.saxonica.com/

From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] 
On Behalf Of David Maze
Sent: 27 July 2006 17:40
To: xmlschema-dev@w3.org
Subject: RE: Can xsi:type cause the element declaration to get ignored?


Okay, that makes sense for the top-level element case.  But what if it's 
not the top-level element? 

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
  <xs:element name="int" type="xs:integer"/> 
  <xs:element name="container"> 
    <xs:complexType> 
      <xs:sequence> 
        <xs:element ref="int" minOccurs="0" maxOccurs="unbounded"/> 
      </xs:sequence> 
    </xs:complexType> 
  </xs:element> 
</xs:schema> 

<container> 
  <int xsi:type="xs:string">4</int> 
</container> 

The container element is valid only if none of its children are invalid, 
which implies that all of the children need to be validated as per 
cvc-assess-elt.  In validating container, we get to cvc-elt 5.2.1, which 
calls cvc-type; cvc-type 3.2 calls cvc-complex-type; cvc-complex-type 2.4 
calls cvc-particle; skipping two levels, cvc-particle 2.3.2 merely 
establishes that the .context-determined declaration. for when 
cvc-assess-elt is called on the inner int is the global element 
declaration for it.  Does something along this path force you to believe 
the element declaration over the xsi:type? 

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 


"Michael Kay" <mike@saxonica.com> 
Sent by: xmlschema-dev-request@w3.org 
07/27/06 11:23 AM 


To
David Maze/Cambridge/IBM@IBMUS, <xmlschema-dev@w3.org> 
cc

Subject
RE: Can xsi:type cause the element declaration to get ignored?









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@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of David Maze
> Sent: 25 July 2006 21:39
> To: xmlschema-dev@w3.org
> 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
>