Raymond,
How does this relate to the contribution resolution mechanism described
by the SCA specifications?
Yours, Mike.
Raymond Feng wrote:
Hi,
We currently use XmlSchema to load XSDs. To resolve the import/include
directives using our schemes, we provide an implementation of
org.apache.ws.commons.schema.resolver.URIResolver and set it to
org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the
schemaLocation attribute for the <xsd:import> or <xsd:include> is set.
Now we would like to handle the cases where the schemaLocation attribute
is not present. For example, <xsd:import namespace="http://ns1"/>.
Without the schemaLocation, we resolve the import/include by namespace.
In this case, we already have a map keyed by namespace for a list of
XmlSchema objects loaded from a catalog or other files and we want to
reuse them. Would it be possible to open the
XmlSchemaCollection.getSchema(SchemaKey) method so that we can
override/customize the behavior to associate existing XmlSchema
instances to a SchemaKey? BTW, using a singleton of XmlSchemaCollection
to keep the schema map is not always feasible.
Another observation is that a NPE will be thrown if the
URIResolver.resolveEntity() returns null. Is there any way to disable
the aggressive resolving/loading of import/include?
[EMAIL PROTECTED]
Raymond Feng
Apache Tuscany
---------------------------------------------------------------------
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]
