Hi, Raymond,
    We encountered the same problem when implementing SDO's XSDHelper. Where we 
used EMF's xsd tool package for resolve xsd. Wherein we just implemented our 
own XSDSchemaLocator and added it to the resource's adapters, then we can do 
everything in locating the import/include xsd. It works fine.
    I don't know if XmlSchema have any thing alike. 

----- Original Message ----- 
From: "Mike Edwards" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Wednesday, July 25, 2007 9:33 PM
Subject: Re: [XmlSchema] Pluggability for XSD import/include resolvers?


> 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]
>

Reply via email to