Mark,
 
All of the schema stuff is at prototype stage, since the spec keeps changing.
----- Original Message -----
Sent: Tuesday, December 21, 1999 11:11 AM
Subject: bugs in XML4J 3.0 EA?

Obligatory disclaimer: I'm new to this list and was routed here for feedback by the Xerces documentation.  If this is the wrong list or these bugs have already been reported, my apologies...
 
I'm using XML4J 3.0 EA with JDK 1.2.2, and I've hit a few problems with XML Schema validation, to wit:
 
(1) Using ORDER="all" in an archetype causes the following exception to be thrown during parsing:
 
Unknown ContentSpecNode.NODE_XXX value
 at org.apache.xerces.framework.XMLParser.reportError(XMLParser.java:1273)
 at org.apache.xerces.validators.schema.XSchemaValidator.checkContent(XSchemaValidator.java:1109)
 at org.apache.xerces.validators.schema.XSchemaValidator.endElement(XSchemaValidator.java:532)
 at org.apache.xerces.framework.XMLParser.callEndElement(XMLParser.java:1858)
 at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1245)
 at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
 at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1129)
 
Can you post a file that causes this to happen.
 
(2) Neither scale nor precision appear to actually be enforced for the decimal base type, e.g. a datatype derived from decimal with precision 10 and scale zero will not cause a parse error when a number like 3.1415927 or 123345789123 appears in the document.
Correct.  This is because we're not using BigDecimal yet.  When these validators were first written there was a lot of
controversy in the Schema working group about the numeric types.  So rather than implement something that didn't change,
we did a "cheap" job.  Now that things are settling down, we need to go back an plug the holes.
(3) Using any sort of lexicalRepresentation in a datatype causes the following exception to be thrown during parsing:
 
java.lang.NullPointerException
 at java.util.Hashtable.put(Hashtable.java:381)
 at org.apache.xerces.validators.schema.XSchemaValidator.traverseDatatypeDecl(XSchemaValidator.java:2241)
 at org.apache.xerces.validators.schema.XSchemaValidator.traverseSchema(XSchemaValidator.java:1729)
 at org.apache.xerces.validators.schema.XSchemaValidator.loadSchema(XSchemaValidator.java:1701)
 at org.apache.xerces.framework.XMLParser.scanAttValue(XMLParser.java:1931)
 at org.apache.xerces.framework.XMLDocumentScanner.scanElement(XMLDocumentScanner.java:1800)
 at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:991)
 at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
 at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1129)
 
Again, can you post a file that causes this to happen?
 
A couple of feature requests too:
 
(1) support for the various date and time datatypes
(2) support for pattern-matching lexical representations
(3) support for nested element declarations
(4) use of Java BigDecimal as the underlying type for XML Schema decimal, so that min and max can be arbitrary precision, like the specification.
 
All of these are in the works.   Stay tuned.
 
Thanks for listening,
markl
 
Mark L. Lambert
Senior Architect
TIBCO Software Inc.

Reply via email to