- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Mon, 15 Mar 2004 10:41:57 -0500
- To: "Arthur Ryman" <ryman@ca.ibm.com>
- Cc: <www-ws-desc@w3.org>
> 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. +1 :) --G > 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 > > To > <ygoland@bea.com>, Arthur Ryman/Toronto/IBM@IBMCA > cc > "Martin Gudgin" <mgudgin@microsoft.com>, <paul.downey@bt.com>, > <www-ws-desc@w3.org>, <www-ws-desc-request@w3.org> > Subject > Re: WSDL Import/Include Locations > > > > > > > > Arthur: > > I think you're making some assumptions about the processor's behavior > which > 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 > means > 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 > need > 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. > > --Glen > > > 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 > document > > 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 > 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 > > > > > > > >
Received on Monday, 15 March 2004 10:42:20 UTC