DOM3 schema-location parameter behaviour

[Lucian Holland <le...@decisionsoft.com>]

Hi,

I've noticed some slightly strange  behaviour when I set the 
"schema-location" parameter through the DOMConfiguration interface on 
DOMParserImpl. The primary schema for the document I'm parsing defines 
some elements as being in the substitution group of elements in other 
namespaces; because of the way it's being used, neither the instance nor 
the schema provide schemaLocations for the namespaces they use, and these 
need to be set through the parser.

Using the old external-schema-location property, this all worked fine, but 
when I moved to using the new DOMParserImpl, I could no longer use this 
property, presumably because I should be setting the DOM3 
"schema-location" parameter instead. Unfortunately, when I started using 
this, I ran into problems - some of the elements from other namespaces 
that the primary schema referred to couldn't be found.

After a bit of investigation, it turned out that the order in which the
URIs appear in the "schema-location" string is crucial. If any of the
schema documents pointed to by the URIs in it require any of the documents
pointed at by the other schema locations in it, in order to resolve the
namespaces they use, then these other schema locations must come before
the location of the schema that needs them... That's a bit tortuous, so as
an example:

3 documents:
InstanceDoc 
   - URI http://foo.com/instance.xml
   - elements from namespace http://foo.com
   - no schemaLocation given for http://foo.com
SchemaDoc  
   - URI http://foo.com/schema.xsd
   - targetNamespace http://foo.com
   - some elements in the substitution group of elements in the 
     http://foo2.com namespace
   - No schemaLocation given for http://foo2.com
SecondSchemaDoc
   - URI http://foo2.com/schema.xsd
   - targetNamespace http://foo2.com
   

If I set the schema-location property to "http://foo2.com/schema.xsd
http:/foo.com/schema.xsd" it all works fine. But if I set it to
"http://foo.com/schema.xsd http://foo2.com/schema.xsd"
 xerces complains that it can't find things defined in the foo2 schema. I
assume that this is because it is parsing each of the schema docs in the
schema-location string before it starts on the instance document, and
presuming that it will have everything it needs to do this before it
starts each one.

I had a look at the DOM3 spec, and it doesn't really deal with this at all 
- in fact it seems to imply that the property is more to do with specifying 
the "current schema", which I take to be the schema for the main namespace 
used in the instance document. There's certainly nothing about ordering.

I suppose the question is: is this right? Xerces doesn't appear to be 
doing anything that actually contravenes any spec text (which may be an 
argument for posting something to the spec list suggesting a clarification 
here, I suppose); on the other hand, this behaviour isn't entirely 
helpful, since it requires anyone using this property to establish the 
nature of all the dependencies between the relevant documents before they 
start parsing, which is quite a significant extra overhead... Any 
suggestions?

Lucian

-- 
Lucian Holland, Software Engineer      +44-1865-203192
DecisionSoft Limited                   http://www.decisionsoft.com
XML Development and Services



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org