W3C home > Mailing lists > Public > www-ws-desc@w3.org > March 2004

Re: WSDL Import/Include Locations

From: Arthur Ryman <ryman@ca.ibm.com>
Date: Sun, 14 Mar 2004 21:26:33 -0500
To: "Glen Daniels" <gdaniels@sonicsoftware.com>
Cc: "Martin Gudgin" <mgudgin@microsoft.com>, paul.downey@bt.com, www-ws-desc@w3.org, www-ws-desc-request@w3.org, ygoland@bea.com
Message-ID: <OFDC65FAB4.BA2A300C-ON85256E58.000C4ADC-85256E58.000D676B@ca.ibm.com>

I guess my note was unclear since I intended it to show that the processor 
could keep on going even if the first import failed. In fact, both imports 
could fail and the processor could still succeed if the document didn't 
actually refer to any component in the imported namespace.

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063
intranet: http://w3.torolab.ibm.com/DEAB/

"Glen Daniels" <gdaniels@sonicsoftware.com> 
Sent by: www-ws-desc-request@w3.org
03/14/2004 12:08 PM

<ygoland@bea.com>, Arthur Ryman/Toronto/IBM@IBMCA
"Martin Gudgin" <mgudgin@microsoft.com>, <paul.downey@bt.com>, 
<www-ws-desc@w3.org>, <www-ws-desc-request@w3.org>
Re: WSDL Import/Include Locations


I think you're making some assumptions about the processor's behavior 
we explicitly are not going to specify, IIRC.

In particular, we make no requirement for a "fast fail" with import -
therefore a processor has a choice whether to resolve imported namespaces
when it first encounters the import (your assumption) or on an "as-needed"
basis when resolving component references later in the document.  This 
that if a processor chooses to do "read-as-required" it will probably only
read the first available import of a given namespace, and then have no 
to read any redundant ones unless there are references to components not
defined in the first one.  Hence, the processing time cost is only for
certain architectures, and not a given for all processors.


> The WSDL processor will still try to load each URL because the two
> documents could contain different definitions in the f:00 namespace.
> However, this still provides some degree of failover in the case the
> documents have the same contents.
> When the processor sees the first <import> it adds the f:oo namespace to
> the set of imported namespaces so that definitions in the current 
> can legally refer to any components in the f:oo namespace.
> The processor then ties to load fileA, which may or may not work. If it
> works, the components in fileA are added to the set of known components.
> Similarly for fileB. If both fileA and fileB are reachable and have the
> same content then the only downside is the extra processing time.
> So if you want failover, you can have it, but you pay a price in
> processing time.
> Arthur Ryman,
> Rational Desktop Tools Development
> phone: +1-905-413-3077, TL 969-3077
> assistant: +1-905-413-2411, TL 969-2411
> fax: +1-905-413-4920, TL 969-4920
> mobile: +1-416-939-5063
> intranet: http://w3.torolab.ibm.com/DEAB/
> www-ws-desc-request@w3.org wrote on 03/12/2004 02:52:16 PM:
> > 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 
> > both define components in namespace FOO. The two files do not define 
> > common components and the two files do not include each other. In 
> > 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 
> > 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
> >
Received on Sunday, 14 March 2004 21:27:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:47 UTC