Comments and questions inline.
Mike Edwards wrote:
Hi,
A few thoughts....
<snip>
>> We have two options here:
>>
>> a) Plugin a tuscany-specific resolver for WSDL4J
>> (javax.wsdl.xml.WSDLLocator) and XmlSchema
>> (org.apache.ws.commons.schema.resolver.URIResolver).
>>
>> This option can handle location case 1, 2 and 3. For 2, we probably
need
>> some context from the contribution service.
>>
>> The difficulty is that both resolvers expect to take an
InputSource. For
>> location case 4 (empty or not present), we don't have a corresponding
>> InputSource.
>
> I was going to respond with a long list of pros-cons for both options,
> then deleted all my comments to ask a simple question :). Why can't we
> return an InputSource for the contents of the imported document?
>
> Well, for the import/include that can be resolved to a document, we
> return the InputSource. I have said that it works for location case
1, > 2 and 3. But if the import/include only doesn't have the
> schemaLocation attribute, what InputSource should we return?
Well, it seems valid to me to go use the SCA resolution mechanism - it
is simple enough to say, either use the WSDL or XML approach (and
require a location) but if there is no location, then this isn't going
to work and SCA takes over. I note that if the location is left out
in the case of the included/imported file being in the same
contribution as the source file, then things are simple and the SCA
rules will find it.
If it is elsewhere, then SCA at least defines an algorithm to follow
to attempt to find the referenced file.
How about this then:
- if the location is not specified you get the first WSDL file we find
matching the namespace in the current contribution or in a contribution
imported by an SCA <import>
- if you're not happy with that (because for example you have multiple
WSDLs sharing the same namespace), please specify a correct location in
your WSDL
Is this too simplistic? Do you see any realistic scenarios that we
wouldn't be able to support with this approach?
> A related question, for an artifact processer that loads multiple
> artifacts following the import/include directives, how can we avoid
> the duplicate loading? For example, we have a.wsdl imports b.wsdl,
> both a.wsdl and b.wsdl are in the same contribution and they are
> processed by the WSDL artifact processor. We probably don't want to
> load b.wsdl twice in this case.
Why actually load anything before it is clearly required?
I'm not quite following yet, how does one know that file X.wsdl is
clearly required?
But once it is loaded, keep it around. This should be true for all
artifacts.
+1 for all artifacts that we handle ourselves, but WSDL4J and the
XmlSchema lib do not seem to support this. Has anybody raised this issue
to them?
Yours, Mike.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
