Re: schema xsi:type validation question

thanks much.  I will post on the xmlschema comments list then.  I will 
also read the TAG lists and post there if I don't see any similar use 
cases already posted.  We actually have workarounds.  I was just really 
hoping extension worked like I thought it would originally.  It would 
have been nice and clean in an object oriented sort of way.  Hopefully 
in the future, it can work that way with special features turned on.
thanks,
dean

noah_mendelsohn@us.ibm.com wrote:

>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 Saturday, 22 November 2003 11:17:33 UTC