Re: schema xsi:type validation question

The whole notion of how to version and extend vocabularies is under active 
discussion by the schema WG.  Yours is one of many, many potentially 
interesting use cases.   It's understood that the current Schema design 
only handles a very small fraction of the range of things that someone, 
somewhere wants or needs to do regarding evolution of vocabularies, 
interactions between parties with imperfect knowledge of each others' 
variants', etc.

In particular, the xsi:type idiom was not designed to be used in the 
manner you imply:  I.e. to be ignorable by those who don't have the 
appropriate referenced schema.  I can see why you would want to do this, 
but as you correctly quote the specification, the value in the xsi:type 
attribute must resolve.  A partial if clumsy workaround is for you to 
define your own ava:ExtendedElement in your own private schema document 
for that namespace that you don't have, and to define it as the original 
ns1:element extended with a wildcard, which is what I think you are trying 
to achieve.  This would work if you knew in advance about the extension, 
or had a tool smart enough to generate these dummy schemas on the fly.

Another idiom, which may be too late for you, is to define the original 
ns1:element as ending in a wildcard with lax validation.  The inventor of 
the ava namespace  can then provide his/her additional definition for 
ava:moredata when validating at that end of the connection.  If desired, 
that person could also redefine ns1:element to require the ava:moredata 
element.  In either case, you'd want to avoid the explicit xsi:type in a 
situation where someone will be validating without access to the 
referenced declaration.

I'm not arguing that these workarounds meet your needs well, I'm just 
saying this is how things work.  Both the schema workgroup and the TAG are 
actively considering versioning issues.   The tag in particular has 
published some thoughts on public lists, and I'm sure they'd appreciate 
some thoughtful input.  The Schema WG is still at the stage of deciding 
how we want to organize our analysis, and which issues matter.  I think a 
use case like this sent to the schema comments list would be very helpful 
as input.  Thank you.

BTW:  I'm off on vacation in a few mins for a week, then at the SOAP WG 
meeting the following week.  I won't be responding to any correspondence 
on this or similar threads for awhile.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Dean Hiller <dhiller@avaya.com>
Sent by: xmlschema-dev-request@w3.org
11/21/2003 10:59 AM

 
        To:     xmlschema-dev@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        schema xsi:type validation question



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

Received on Friday, 21 November 2003 17:49:49 UTC