We have just moved from validation through DTD’s to validation through schemas. But after that I had much trouble parsing documents. The first documents parsed went just fine and everything was peachy. Then I came to a point where a document based on a different schema should be parsed. And the system goes haywire and clamed that the root element wasn’t declared. I thought WTF and started debugging. I quickly asserted that the document and schema is valid (thank god for XMLSPY). So the problem was indeed Xerces. A couple of aggravating debugging hours later I have pinpointed the problem.
There is IMHO a serious bug in GrammarResolver. Parsed schemas is cached on target namespace. Because we don’t put our schemas inside namespaces and use noNamespaceSchemaLocation, all our parsed schemas are hashed on an empty URI. Now you're thinking: So what is the problem? Well the problem is this. First we parse a document based on schema A with root element A_root. The schema is cached on “”. Everything is fine. Then we parse another document based on schema A. The cache finds the schema for “” and validates. Everything is fine. THEN we parse a document based on schema B with root element B_root. The parser looks in the cache, finds the schema for “” (type A) and validates. This of course results in a shitload of errors and a failed parse. Of course, if I turn of the caching of schemas then the problem doesn’t occur. To hash on target namespace in the cache seems like a good idea when using namespaces but it doesn’t work for the default namespace. I probably don't see the whole picture here, but why hash on the target namespace and not the systemid of the loaded schema document? Erik Rydgren Software engineer Aptic AB Kåsatorpsvägen 5 SE 541 34 SKÖVDE Sweden tfn: +46(0)500-416506 fax: +46(0)500-413215 mail: [EMAIL PROTECTED] site: www.aptic.se --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
