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.
|