David Bertoni wrote:
>
> You can't store two different schemas with the same target namespace URI
> in the same grammar pool. As you've noticed, this is because the pool
> uses the target namespace URI as the key. It works this way because
> that's how the parser finds a grammar for a particular element during
> validation -- it uses the namespace URI of the element to validate.
>
I see. So if I have a scenario as follows: I want to validate a XML file
with schema A. Schema A includes schema B (both have the same namespace).
When using one of the parsers and calling loadGrammar to load schema A, the
parser will try to resolve schema B but will not cache it? Where does it go
then?
And if afterwards I try to use that XMLGrammarPool with a different parser
will the same XML pass schema validation? Or will it fail because it can't
find schema B?
David Bertoni wrote:
>
> lock() allows for thread-safe reads, but not writes, because it prevents
> adding new grammars and implements a thread-safe XMLStringPool.
> However, you need to be very careful with using lock() and unlock()
> since these member functions are not thread-safe themselves. The use
> case is to add a bunch of grammars, lock it to ensure the pool is not
> mutated, then allow multiple threads to have read-only access to it. In
> particular, you should never lock or unlock a grammar pool after you've
> given it to a parser instance.
>
> If you really want a fully thread-safe grammar pool, you'll have to wrap
> the existing pool and use a mutex to synchronize the public member
> functions.
>
Ok, I think I got it. I'm not sure how I would use this in my system though.
Basically I have something like 100 schemas that the XMLs I validate might
need. So if I understand what you're saying correctly, before starting to
actually parse the XMLs I should load all those schemas into a
XMLGrammarPool and only when that loading is completed I should start the
parsing.
--
View this message in context:
http://www.nabble.com/XMLGrammarPool-issues-tp16851037p16892292.html
Sent from the Xerces - C - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
