Hi Eric and Alberto,
There is a 4th solution: implement your own XMLGrammarPool! The grammar
resolver will always consult the grammar pool registered with the parser
when it needs a new grammar, and your pool is perfectly free to decide
which grammar object to return whatever way it likes. Note also that if it
returns nothing, the parser will build a grammar and offer it to the pool
to cache; so your pool can even change with time if it feels like it.
If you go this route, let us know how it goes; I'm not sure how many folks
have used the extensibility built into the grammar caching mechanism of the
parser.
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
Alberto Massari
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
s.com> cc:
Subject: Re: GrammarResolver and
noNamespaceSchemaLocation
02/05/2004 09:04
AM
Please respond to
xerces-c-dev
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]
