Daniel Jackson wrote:
David Bertoni wrote:
There may be differences in how the two parsers build a schema from the
constituent parts. The schema recommendation is a little loose in this
area, so there can be inconsistencies.
It sounds like Xerces-C is unable to find the definitions for part(s) of
the schema. The likely cause is the limitation that single top-level
schema document must include all of the other components for the target
namespace URI.
Yes, Xerces-C can't find the definitions but they are out there in the
schemas. I mean I checked the error saying some element can't be found and I
went and found that element defined somewhere. And the problematic schema
did include/import the right schema. I could also see calls to resolveEntity
resolving the "missing" schema.
Xerces-C uses a hash table keyed on the target namespace URI. If you use
loadGrammar(), the parser will build a Grammar object for each of the
target namespaces that it reaches by parsing the entity in the InputSource
you provide. If you try to load another grammar that contains more
components for a target namespace URI the parser has already seen, it will
skip those components, since it already has a grammar for that namespace URI.
So if I understand you correctly in the situation I described with the docx
schemas I should create the in-memory schema that includes all others per
namespace?
It doesn't have to be in memory. You could simply create a top-level
schema document that includes all of the other entities that contain the
schema components you're interested in.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
