Re: WSDL Import/Include Locations

Although I now believe I understand the distinction I believe this is 
something subtle enough to deserve a specific call out in part 1.

Section 4.2 current contains the sentence "Directly imported means that 
component importation is not transitive; components imported by one of 
the imported documents are not available to the original importing 
document unless the are imported directly by that document."

I would propose inserting an additional sentence after this one that 
reads "Note, however, that if a directly imported document includes 
another document then the components in the included document are 
available to the original importing document."

This then brings up another scenario that I'm not even sure is legal. 
Imagine I have a WSDL namespace FOO and two files, FileA and FileB that 
both define components in namespace FOO. The two files do not define any 
common components and the two files do not include each other. In other 
words, each file is completely stand alone. In that case if a WSDL for 
namespace BAR should have:
<import namespace="f:oo" location="http://example.com/fileA"/>
<import namespace="f:oo" location="http://example.com/fileB"/>

And if the WSDL should optimize by only successfully downloading one of 
the two links then components needed by WSDL BAR would not be downloaded.

This scenario presumes however that it is legal to have two completely 
independent files defining non-overlapping components in the same 
namespace that do not reference each other. Is that legal?

	Thanks,

		Yaron

Martin Gudgin wrote:

> 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 Friday, 12 March 2004 14:52:22 UTC