xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Smith, Doug" <Doug.Sm...@fmr.com>
Subject RE: Desperate: Very strange Schema validation bug in Xerces?
Date Fri, 13 Oct 2000 23:19:18 GMT
 I just went through this. In my case I was using schemas without a target
namespace, with the same element names in the different schemas with
slightly different definitions.

I believe the problem has to do with symbol spaces, which element
definitions belong to. In the abscence of being scoped to a namespace,
everything gets lumped into the same symbol space -- at least that's how I
understand it - look at the XML Schema specs for details.

Bottom line was I was able to fix it by binding each of my schemas to a
unique namespace.

Hope this helps. Good luck.

--Doug Smith

-----Original Message-----
From: Travers Waker
To: general@xml.apache.org
Sent: 10/13/00 4:18 AM
Subject: Desperate:  Very strange Schema validation bug in Xerces?

Hi.

I have just spent 3 days trying to isolate a very strange bug I'm
picking up
with Schema validation in Xerces 1.2.0 .  I'm hoping someone else has
come
accross this one already, or it rings a bell with the developers.

I am using Xerces via JDOM, but I'm pretty confident that the problem is
with Xerces, and not JDOM, since JDOM just makes use of Xerces' ability
to
validate with Schemas.

Here's the problem:  Xerces seems to mix up the regular expressions of
the
Schema it used previously with the schema it is using now.  For example,
say
I first parse a message that uses SchemaA for validation, and the first
element defined in SchemaA, let's call it ElementA, must match the
regular
expression "\d{8}" (i.e. 8 digits).  Then I parse a different message
that
uses SchemaB for validation.  The first element that SchemaB expects to
find
in an instance document (let's call it ElementB, and it has a different
name
ElementA) is specified to match the regular expression ".{1,40}" (i.e.
between 1 and 40 characters).  HOWEVER,  Xerces ignores the regular
expression given for ElementB (".{1,40}) and instead uses the regular
expression from the previously used Schema ("\d{8}") to validate
ElementB.

It's as if there is something left behind of the old Schema lurking in
the
parser, even though I've specified a new schema at the top of the second
message to be parsed.  It seems to me that there is some type of memory
problem where certain constructs are overwriting the old ones, and some
parts of the old ones are left behind, or maybe some type of table is
being
referenced with a key that is not unique when it is supposed to be.

Here is a realtively simple example illustrating the problem.

My java test program:
------------------------------------------------------------------------
----
--------------
package tests.jdom;
import java.io.File;
import org.jdom.*;
import org.jdom.input.*;

class JdomBugTest {

  public static void main(String[] args) throws Exception {
    SAXBuilder builder1 = new SAXBuilder(true);  // true = validation
enabled.
    SAXBuilder builder2 = new SAXBuilder(true);  // true = validation
enabled.
    Document doc1 = builder1.build(new File("bugXml.xml"));
    Document doc2 = builder1.build(new File("bugEft.xml"));
  }
}

The output from my program:
(THIS SHOULD NOT FAIL VALIDATION BECAUSE "BP TEST STORE" DOES MATCH
".{1,40}", BUT "\d{8}" FROM THE PREVIOUSLY USED SCHEMA (bugXml.xsd) IS
BEING
USED INSTEAD.WEIRD.)
------------------------------------------------------------------------
----
--------------
org.jdom.JDOMException: Datatype error: Value 'BP TEST STORE' does not
match
regular expression facet '\d{8}'..: Error on line 7 of document
file:/C:/Java/tests/jdom/bugEft.xml: Datatype error: Value 'BP TEST
STORE'
does not match regular expression facet '\d{8}'..
 at org.jdom.input.SAXBuilder.build(SAXBuilder.java:310)
 at org.jdom.input.SAXBuilder.build(SAXBuilder.java:373)
 at org.jdom.input.SAXBuilder.build(SAXBuilder.java:354)

The file bugXml.xml:
------------------------------------------------------------------------
----
--------------
<?xml version="1.0" encoding="US-ASCII"?>

<VagasTempTag xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation='bugXml.xsd'>

<vagasFinancialRequest>
  <date>20000628</date>
</vagasFinancialRequest>

</VagasTempTag>

The file bugXml.xsd:
------------------------------------------------------------------------
----
--------------
<?xml version="1.0" encoding="US-ASCII"?>
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<xsd:element name="VagasTempTag">
  <xsd:complexType>

    <xsd:element name ="vagasFinancialRequest">
      <xsd:complexType>

        <xsd:element name="date">
          <xsd:simpleType base="xsd:string">
            <xsd:pattern value="\d{8}"/>
          </xsd:simpleType>
        </xsd:element>

      </xsd:complexType>
    </xsd:element>

  </xsd:complexType>
</xsd:element>

</xsd:schema>

The file bugEft.xml:
------------------------------------------------------------------------
----
--------------
<VagasTempTag xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation='bugEft.xsd'>

<eftPreAuthorisationRequest>
  <cardAcceptorName>BP TEST STORE</cardAcceptorName>
</eftPreAuthorisationRequest>

</VagasTempTag>

The file bugEft.xsd:
------------------------------------------------------------------------
----
--------------
<?xml version="1.0" encoding="US-ASCII"?>
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<xsd:element name="VagasTempTag">
  <xsd:complexType>
    <xsd:element name="eftPreAuthorisationRequest">
      <xsd:complexType>
        <xsd:element name="cardAcceptorName">
          <xsd:simpleType base="xsd:string">
            <xsd:pattern value=".{1,40}"/>
          </xsd:simpleType>
        </xsd:element>
      </xsd:complexType>
    </xsd:element>
  </xsd:complexType>
</xsd:element>

</xsd:schema>



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Mime
View raw message