Well I understand the concept about namespaces. I just thought that the parser did handle caching on a URI level and not on namespace level. Thanks for clearing that up.
/ Erik > -----Original Message----- > From: Alberto Massari [mailto:[EMAIL PROTECTED] > Sent: den 5 februari 2004 15:04 > To: [EMAIL PROTECTED] > Subject: Re: GrammarResolver and noNamespaceSchemaLocation > > Eric, > you shouldn't use schema caching if you have different schemas sharing the > same namespace (being this the empty one or not). A namespace URI is a > "domain", is like saying "when I am talking about music a record is > something that has songs in it; when talking about sports a record is the > best performance". You are using two schemas, sharing the same "domain" > label: nothing wrong with that, provided that you don't mix them. > > So, either: > a) turn off schema caching, > b) use different DOMBuilder/DOMParser to parse XML documents using > different schemas > c) use a targetNamespace in your schemas > > Alberto > > At 14.42 05/02/2004 +0100, Erik Rydgren wrote: > >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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
