Re: WSDL Import/Include Locations

Let's say that I have a WSDL namespace FOO that is defined by two 
different files, A & B. File A includes File B.

I now want to define a WSDL namespace BAR and I want to use components 
that are defined in namespace FOO. One could imagine an import statement 
of the form:
<import namespace="f:oo" location="http://example.com/fileA"/>

However it turns out that one of the components I want to directly 
reference is defined in file B. Per section 4.2 in part 1 I can't 
directly reference any components in file B unless I import it. So now 
the import section will have:
<import namespace="f:oo" location="http://example.com/fileA"/>
<import namespace="f:oo" location="http://example.com/fileB"/>

Gudge, if I understood your previous point you suggested that if one had 
multiple imports for the same namespace then one was free to assume that 
they all point to the same infoset content and so one only needed to 
download one of the links, thus neatly solving my concerns about 
redundancy and performance.

But in this case that assumption doesn't appear safe. If the WSDL system 
only imported one of the two links from namespace FOO then the WSDL 
definition would miss referenced components and fail.

Did I miss something?

	Thanks,
		Yaron

paul.downey@bt.com wrote:

> Yaron wrote:
> 
>  > One of the most common ways to deal with unreliability is to
>  > make information available at distinct locations. The advantage
>  > of making data available at distinct locations is that not only
>  > does it provide reliability in the face of endpoint failures but
>  > it also provides reliability in the face of network failures.
> 
> 
> Actually something that has always bothered me about the /list/ of
> locations in WSDL and Schema: if a list is essential for resilience
> then why don't other languages such as HTML have a list of URIs in
> <a href='...' etc ?
> 
> My most common use for the location /list/ has been to put a relative
> URI followed by an absolute URI so that a the same schema may be used
> stand alone on my laptop before being deployed on Web server elsewhere.
> 
> Also I have a competing use-case against multiple locations:
> 
> Before signing-off a Web service we test and validate the service
> using a captured WSDL saved in our configuration management system.
> This captured WSDL must be stand-alone since the WSDL published by
> the service may later change. It's also not acceptable to store a
> serialisation of the infoset since this is different to the actual
> published documents, invalidating any regression testing.
> 
> So we need to not only store the root document but any other
> documents referenced and in a way that emulates how a consumer
> of the actual service would have worked.
> 
> Here the redundancy lists only exasperates this difficulty since
> it is possible for two test runs to be presented with two different
> sets of documents. 
> 
> So a single URI in the location and having some environmental change
> to subvert the processor (a 'PATH' variable) would be preferable
> here rather than having to edit the WSDL document and invalidate
> our regression tests.
> 
> Just another reason why concentrating on what is a valid WSDL
> document rather than the behaviour of a WSDL processors is very
> useful.
> 
> Paul
> 
> -- 
> Paul Sumner Downey
> Web Services Integration
> BT Exact
> 
>

Received on Thursday, 11 March 2004 19:28:49 UTC