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]
