Dean,
Parts 1 and 2 of the schema spec are a little hard to get through in this regard, but the non-normative Part 0 makes it a bit clearer. After reading them all through and pondering this a bit, here's what I think you need to do:
Take the base schema definition of:
<xsd:complexType name="ElementType">
<xsd:sequence>
<xsd:element name="data1" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>And, in your own schema that you will reference in your instance documents, define a new complex type derived by extension:
<xsd:complexType name="ElementType2">
<extension base="ElementType">
<xsd:sequence>
<xsd:element name="data2" type="xsd:string"/>
</xsd:sequence>
</extension>
</xsd:complexType>There are two key concepts here:
1) Since the schema is not written with the xs:any element with a processContents="skip" attribute, a schema processor is going to try to validate your "Element" element against its type. The only way to defeat that will be to not validate at all.
2) Schema language allows you to over-ride the type, but the type must be derived by extension or restriction from the base type defined for the element in the schema. This means, of course, that you have to define your new type somewhere. Since you can't alter the base schema, you'll have to create it in your new one.
Haven't had reason to try this, but I think it should work for you.
Mike
At 12:48 PM 11/20/2003 -0700, you wrote:
Let me give you a more global context of what I am trying to do and maybe there is something else I am not thinking of. Many companys wrote servers conforming to a standard and each have their own extensions. I want to validate that I got a Car and process the Car even though the Car was really a CompanyXCar(ie. I am ignoring data from other namespaces). I also can't download each schema as it talks to each server as the app is typically used in very secure locations with no access to the web.
Basically, I want to validate a car is a car and not worry about extra data that was put in by companies that extended the schema.(It would be near impossible to change the standard schema at this point)
thanks for any direction on this,
dean
Sandy Gao wrote:
ie. if it only knew about a car, it would process the car and ignore the Ford specific data, or Honda specific data depending on what type of car it actually received.
But if your Honda car claims that "I'm a Honda, and you have to treat me as a Honda" (via xsi:type), then the schema processor has no choice but to tell you I'm sorry.
The schema spec is very clear on this. When there is an xsi:type in the instance document, its value "must resolve to a type definition", which indicates that if such resolution fails, there is an error.
You might want to consider <redefine>ing the "standard" schema, instead of extending it. This way, you don't need to specify "xsi:type" in your instance. And you can switch between the "standard" and the "redefined" schemas using an entity resolver (or grammar pool in Xerces).
Hope this helps, Sandy Gao Software Developer, IBM Canada (1-905) 413-3255 <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Dean Hiller
<mailto:[EMAIL PROTECTED]:[EMAIL PROTECTED]><[EMAIL PROTECTED] To: [EMAIL PROTECTED]
m> cc:
Subject: Re: dynamic validation, is this a bug
11/20/2003 10:06
AM
Please respond to
xerces-j-user
yeah, can't really do that seeing as how the protocol is a standard(ie. The whole xsd down below is the standard and we want to extend it and add a proprietary feature the protocol doesn't have due to customer requests), and you know how slow standards change. I really need to accomplish it by extension. Should I ask the xerces developers then???? I personally don't like the any element and much prefer the object oriented-ness of schemas where you can extend other base types and add data to them though I haven't gotten them to work yet. ideally, an application would just ignore extra data. ie. if it only knew about a car, it would process the car and ignore the Ford specific data, or Honda specific data depending on what type of car it actually received. thanks, dean
Mike Rawlins wrote:
At 05:27 PM 11/19/2003 -0700, Dean Hiller wrote:
good question. did a quick grep...processContents is not found in the entire schema(schema is 300 pages). Root element looks like so
<xsd:element name="Root" type="RootType/> <xsd:complexType name="RootType"> <xsd:sequence> <xsd:element name="Element" type="ElementType"/> </xsd:sequence> </xsd:complexType>
<xsd:complexType name="ElementType"> <xsd:sequence> <xsd:element name="data1" type="xsd:string"/> </xsd:sequence> </xsd:complexType>
Hmm, not quite what I was expecting. If you want to play around with another approach, you might instead do something like:
<xsd:complexType name="ElementType"> <xsd:sequence> <xsd:element name="data1" type="xsd:string"/> <xsd:any namespace="##any" processContents="skip"> </xsd:sequence> </xsd:complexType>
Then, in your instance document try:
<Element> <data1>some data</:data1> <ava:data2>more data</ava:data2> </Element>
I'm not sure I've got the syntax exactly correct, but this may be closer to what you want and at least get you started. This is approach, of course, just deals with the instance document and schema. I've had a few problems with a similar approach with Xerces, but didn't have time to track them down to closure. However, this or something similar *should* work.
Mike
--------------------------------------------------------------- Michael C. Rawlins, Rawlins EC Consulting <http://www.rawlinsecconsulting.com>www.rawlinsecconsulting.com Using XML with Legacy Business Applications (Addison-Wesley, 2003) <http://www.awprofessional.com/titles/0321154940>www.awprofessional.com/titles/0321154940
---------------------------------------------------------------------
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
--------------------------------------------------------------- Michael C. Rawlins, Rawlins EC Consulting www.rawlinsecconsulting.com Using XML with Legacy Business Applications (Addison-Wesley, 2003) www.awprofessional.com/titles/0321154940
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
