schema xsi:type validation question

  my mail didn't forward with all the info, so here it is again with 
important information that was missing.

I was told this use-case might be useful.  (Read the attached e-mail 
first, then this last sentence)

I couldn't use the xsi:type="ExtendedElement" the way I actually wanted. 
 I guess I am looking for a new feature in schema compliant processors 
allowing them to do a certain type of validation where they only 
validate everything in the specified namespaces.  For extended elements 
in a new namespace, half of the data would be validated(the data in the 
standard namespace).  The other half would just be ignored.
thanks for considering this,
dean

-------- Original Message --------
Subject: schema xsi:type validation question
Resent-Date: Fri, 21 Nov 2003 11:02:17 -0500 (EST)
Resent-From: xmlschema-dev@w3.org
Date: Fri, 21 Nov 2003 08:59:57 -0700
From: Dean Hiller <dhiller@avaya.com>
To: xmlschema-dev@w3.org



Hi all,
   having a huge discussion over on the xerces-J list right now.  I got 
the impression from somone on this list that if I had this XML

<ns1:element xsi:type="ava:ExtendedElement">
   <ns1:data/>
   <ava:moredata/>
</ns1:element>
   
I could validate against the ns1 namespace and ignore the ava namespace. 
 I am being told on the xerces list this is not true according to the 
specification, which I think I may agree that the specification states 
this is not true.(though I don't agree with having that in the spec)

First, let me give a small background on the entire problem.  I am 
writing a client that I want to communicate a standard 
protocol(namespace="ns1" above).  I don't want to use any extensions 
from any companies(namespace="ava" above).  My client is typically 
behind a firewall and can't get the extra schemas.  It only gets what I 
ship with it.  I only ship the standard as I communicate with all 
servers that implement the standard.  Problem is some companies extend 
their schema as above and they all extend differently for the extra 
features they offer.  This naturally makes me want to process and 
validate Element without validating ExtendedElement.

Now to the spec, the spec has item 4.3(spec section pasted below) which 
states the local type definition must be validly derived from the type 
definition.  Unfortunately, since xerces is not given the extended 
schema(or the other 100 companies extension on the standard), it cannot 
verify 4.4 so cannot declare the element to be locally valid.  I 
personally think, this is big mistake to do this, because there are 
situations you just want to validate the superclass without validating 
the subclass, like my above scenario.

----------------------------------------XSD BEGIN 
SPEC------------------------------------
4 If there is an attribute information item among the element 
information item's [attributes] whose [namespace name] is identical to 
http://www.w3.org/2001/XMLSchema-instance and whose [local name] is 
type, then all of the following must be true:
4.1 The ·normalized value· of that attribute information item must be 
·valid· with respect to the built-in QName simple type, as defined by 
String Valid (§3.14.4);
4.2 The ·local name· and ·namespace name· (as defined in QName 
Interpretation (§3.15.3)), of the ·actual value· of that attribute 
information item must resolve to a type definition, as defined in QName 
resolution (Instance) (§3.15.4) -- [Definition:]  call this type 
definition the local type definition;
4.3 The ·local type definition· must be validly derived from the {type 
definition} given the union of the {disallowed substitutions} and the 
{type definition}'s {prohibited substitutions}, as defined in Type 
Derivation OK (Complex) (§3.4.6) (if it is a complex type definition), 
or given {disallowed substitutions} as defined in Type Derivation OK 
(Simple) (§3.14.6) (if it is a simple type definition).
--------------------------------------XSD END 
SPEC------------------------------------

thanks for any help or suggestions here,
dean