Well, I've been able to identify the element which is causing the
ArrayIndexOutOfBounds exception with Xerces-J:
<element name="quantity" type="quantityType">
<archetype>
<attribute name="all" type="boolean" default="false"/>
<attribute name="type" minOccurs='0'>
<enumeration>
<literal>units</literal>
<literal>dollars</literal>
</enumeration>
</attribute>
</archetype>
</element>
<datatype name="quantityType">
<basetype name="decimal"/>
<precision>9</precision>
<scale>2</scale>
</datatype>
Does anyone know why this would choke Xerces?? Am I messing up the syntax
somewhere (this does conform to the September DTD)?
Kito D. Mann
Virtua Communications Corp
[EMAIL PROTECTED]
Wednesday January 26, 2000 05:33 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Kito Mann/PSG/Prudential)
Subject: Possible bug in Xerces-J 1.01 Schema implementation
I've been watching this list for a while, working with IBM's parser and now
Xerces for Java. I just started working with schemas in hopes of avoiding
a whole bunch of custom document handlers for data validation, and I think
I've come across what looks like a bug. I've translated a DTD to a schema
corresponding to the September draft, and it validates fine against the
Septemeber schema DTD. I've also run the DOMParser against a sample
XML file, and now that I've gotten past some errors in my XML file which
the parser caught, I'm left with the following exception:
java.lang.ArrayIndexOutOfBoundsException: -1
at
org.apache.xerces.validators.dtd.ElementDeclPool.getContentSpecNode(Element
DeclPool.java:480)
at
org.apache.xerces.validators.schema.XSchemaValidator.createChildModel(XSche
maValidator.java:1249)
at
org.apache.xerces.validators.schema.XSchemaValidator.getContentModel(XSchem
aValidator.java:1376)
at
org.apache.xerces.validators.schema.XSchemaValidator.checkContent(XSchemaVa
lidator.java:1023)
at
org.apache.xerces.validators.schema.XSchemaValidator.endElement(XSchemaVali
dator.java:533)
at
org.apache.xerces.framework.XMLParser.callEndElement(XMLParser.java:1867)
at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(X
MLDocumentScanner.java:1245)
at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner
.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1138)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1177)
at
dom.wrappers.NonValidatingDOMParser.parse(NonValidatingDOMParser.java:102)
at dom.DOMCount.count(DOMCount.java:116)
at dom.DOMCount.main(DOMCount.java:265)
at symantec.tools.debug.MainThread.run(Agent.java:48)
Since the schema support is in such early stages, I'm assuming this is a
bug. After looking through the code, and inserting a couple of
System.out.println's,
I've determined that getContentSpec() is returning -2, which is being
passed to getContentSpecNode() and consequently causing the error. But,
since
I'm not yet familiar with the code, this is about as far as I've gotten.
Also, since the error-handling doesn't catch unexpected exceptions like
this,
I'm not sure which element or line number the validator is choking on.
Any light would be appreciated :-).
Kito D. Mann
Virtua Communications Corp
