You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Dean Hiller <dh...@avaya.com> on 2003/11/19 21:41:16 UTC

dynamic validation, is this a bug

Hi all,
    I am getting an error that it can't resolve the ExtendedElement.  I 
assume I get this because I purposefully didn't supply the extended 
schema...I only want to be using the standard protocol, and ignore any 
extensions to the schema.  ie.  I want to validate the originalschema 
and ignore additions.  yet, I get the following error......

ERROR: cvc-elt.4.2:  Cannot resolve 'ava:ExtendedElement' to a type 
definition for element 'Element'.

I have the following xml
<Root xmlns:xsi="http://..../XMLSchema-instance"
               xsi:schemaLocation="http://originalschema schema.xsd"
               xmlns="http://originalschema"
               xmlns:ava="http://www.avaya.com">
<Element xsi:type="ava:ExtendedElement">
   <data1>some data</:data1>
   <ava:data2>more data</ava:data2>
</Element>
</Root>

Notice, the ExtendedElement is in a different namespace.  I set the 
xerces parser to do dynamic validation and give it the location of the 
one schema I want to validate against.....
parser.setFeature("http://xml.org/sax/features/validation", true);
parser.setFeature("http://apache.org/xml/features/validation/schema", 
true);
parser.setFeature("http://apache.org/xml/features/validation/dynamic", 
true);
parser.setProperty("http://apache.org/xml/properties/schema/external-schemaLocation", 

               "http://originalschema original.xsd");

Notice, I do not set the location of the avaya schema.  I don't want it, 
and only want to make sure stuff is valid against the originalschema(to 
maintain compatibility).  I ignore anything not from the originalschema 
namespace to maintain compatibility with other companies too that adhere 
to the standard...ie I use no proprietary features, only ones in the 
standard.

Why am I getting the error then?  I thought it was xerces was only 
supposed to validate against a schema it had when the dynamic feature 
was set?  It doesn't have the avaya schema, so shouldn't it just skip it 
and only validate Element and the nested data inside Element since they 
are part of the original namespace.

thanks for any help on this,
Dean



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org


Re: dynamic validation, is this a bug

Posted by Dean Hiller <dh...@avaya.com>.
    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
> www.rawlinsecconsulting.com
> Using XML with Legacy Business Applications (Addison-Wesley, 2003)
> www.awprofessional.com/titles/0321154940
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org


Re: dynamic validation, is this a bug

Posted by Mike Rawlins <mc...@rawlinsecconsulting.com>.
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
www.rawlinsecconsulting.com
Using XML with Legacy Business Applications (Addison-Wesley, 2003)
www.awprofessional.com/titles/0321154940


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org


Re: dynamic validation, is this a bug

Posted by Dean Hiller <dh...@avaya.com>.
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>

thanks,
dean

Mike Rawlins wrote:

> Dean,
>
> How does your original schema http://originalschema schema.xsd define 
> the "Element" element?   I'm not sure exactly how Xerces handles this, 
> but if you don't have it defined correctly in your original schema (as 
> in processContents="lax" or processContents="skip"), you may be 
> getting killed by the default setting (processContents="strict").
>
> Mike
>
> At 01:41 PM 11/19/2003 -0700, Dean Hiller wrote:
>
>> Hi all,
>>    I am getting an error that it can't resolve the ExtendedElement.  
>> I assume I get this because I purposefully didn't supply the extended 
>> schema...I only want to be using the standard protocol, and ignore 
>> any extensions to the schema.  ie.  I want to validate the 
>> originalschema and ignore additions.  yet, I get the following 
>> error......
>>
>> ERROR: cvc-elt.4.2:  Cannot resolve 'ava:ExtendedElement' to a type 
>> definition for element 'Element'.
>>
>> I have the following xml
>> <Root xmlns:xsi="http://..../XMLSchema-instance"
>>               xsi:schemaLocation="http://originalschema schema.xsd"
>>               xmlns="http://originalschema"
>>               xmlns:ava="http://www.avaya.com">
>> <Element xsi:type="ava:ExtendedElement">
>>   <data1>some data</:data1>
>>   <ava:data2>more data</ava:data2>
>> </Element>
>> </Root>
>>
>> Notice, the ExtendedElement is in a different namespace.  I set the 
>> xerces parser to do dynamic validation and give it the location of 
>> the one schema I want to validate against.....
>> parser.setFeature("http://xml.org/sax/features/validation", true);
>> parser.setFeature("http://apache.org/xml/features/validation/schema", 
>> true);
>> parser.setFeature("http://apache.org/xml/features/validation/dynamic", 
>> true);
>> parser.setProperty("http://apache.org/xml/properties/schema/external-schemaLocation", 
>>
>>               "http://originalschema original.xsd");
>>
>> Notice, I do not set the location of the avaya schema.  I don't want 
>> it, and only want to make sure stuff is valid against the 
>> originalschema(to maintain compatibility).  I ignore anything not 
>> from the originalschema namespace to maintain compatibility with 
>> other companies too that adhere to the standard...ie I use no 
>> proprietary features, only ones in the standard.
>>
>> Why am I getting the error then?  I thought it was xerces was only 
>> supposed to validate against a schema it had when the dynamic feature 
>> was set?  It doesn't have the avaya schema, so shouldn't it just skip 
>> it and only validate Element and the nested data inside Element since 
>> they are part of the original namespace.
>>
>> thanks for any help on this,
>> Dean
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>
>
> ---------------------------------------------------------------
> 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: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org


Re: dynamic validation, is this a bug

Posted by Mike Rawlins <mc...@rawlinsecconsulting.com>.
Dean,

How does your original schema http://originalschema schema.xsd define the 
"Element" element?   I'm not sure exactly how Xerces handles this, but if 
you don't have it defined correctly in your original schema (as in 
processContents="lax" or processContents="skip"), you may be getting killed 
by the default setting (processContents="strict").

Mike

At 01:41 PM 11/19/2003 -0700, Dean Hiller wrote:
>Hi all,
>    I am getting an error that it can't resolve the ExtendedElement.  I 
> assume I get this because I purposefully didn't supply the extended 
> schema...I only want to be using the standard protocol, and ignore any 
> extensions to the schema.  ie.  I want to validate the originalschema and 
> ignore additions.  yet, I get the following error......
>
>ERROR: cvc-elt.4.2:  Cannot resolve 'ava:ExtendedElement' to a type 
>definition for element 'Element'.
>
>I have the following xml
><Root xmlns:xsi="http://..../XMLSchema-instance"
>               xsi:schemaLocation="http://originalschema schema.xsd"
>               xmlns="http://originalschema"
>               xmlns:ava="http://www.avaya.com">
><Element xsi:type="ava:ExtendedElement">
>   <data1>some data</:data1>
>   <ava:data2>more data</ava:data2>
></Element>
></Root>
>
>Notice, the ExtendedElement is in a different namespace.  I set the xerces 
>parser to do dynamic validation and give it the location of the one schema 
>I want to validate against.....
>parser.setFeature("http://xml.org/sax/features/validation", true);
>parser.setFeature("http://apache.org/xml/features/validation/schema", true);
>parser.setFeature("http://apache.org/xml/features/validation/dynamic", true);
>parser.setProperty("http://apache.org/xml/properties/schema/external-schemaLocation", 
>
>               "http://originalschema original.xsd");
>
>Notice, I do not set the location of the avaya schema.  I don't want it, 
>and only want to make sure stuff is valid against the originalschema(to 
>maintain compatibility).  I ignore anything not from the originalschema 
>namespace to maintain compatibility with other companies too that adhere 
>to the standard...ie I use no proprietary features, only ones in the standard.
>
>Why am I getting the error then?  I thought it was xerces was only 
>supposed to validate against a schema it had when the dynamic feature was 
>set?  It doesn't have the avaya schema, so shouldn't it just skip it and 
>only validate Element and the nested data inside Element since they are 
>part of the original namespace.
>
>thanks for any help on this,
>Dean
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-j-user-help@xml.apache.org

---------------------------------------------------------------
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: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org