RE: WSDL Import/Include Locations

If A includes B then when C imports A all the constructs in A and B are
visible to C. The text you refer to in Section 4.2 is about components
that A *imports* not components that A *includes*

Gudge

> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com] 
> Sent: 12 March 2004 00:28
> To: Martin Gudgin
> Cc: paul.downey@bt.com; ryman@ca.ibm.com; www-ws-desc@w3.org
> Subject: 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 20:11:41 UTC