- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Fri, 7 Nov 2003 07:53:14 -0800
- To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, "David Booth" <dbooth@w3.org>, "Anne Thomas Manes" <anne@manes.net>, "Mark Baker" <distobj@acm.org>, "Glen Daniels" <gdaniels@sonicsoftware.com>
- Cc: <www-ws-desc@w3.org>, <paul.downey@bt.com>
IIRC there was at one point a placeholder section in Part 1 for describing the processing model. One could argue that Sections 2.14, 2.15, 2.16, 3, 4 and 6 are all in some way related to how WSDL processors work. These are things all WSDL processors have to do. For example, a WSDL processor which was unable to resolve QName references (Section 2.16) would not be much use! I don't feel strongly about having a specific processing model section. I think that provided implementers know what they have to do in BOTH success and failure cases then how the information is presented is largely a matter of style. And I think the current component-model presentation works. That said, we do in several places say 'it is an error' without saying what behaviour should result e.g. In section 2.1.3 we say "It is an error if two Interface Operation components have the same value for their {name} and {target namespace} properties but are not equivalent." There are other places where we do mandate particular behaviour from a WSDL processor. e.g. in Section 6.1.1 we say "If a mandatory extension element is processed, the WSDL processor MUST either agree to fully abide by all the rules and semantics signaled by the extension element's qualified name, or immediate cease processing (fault)." So, I think we do have SOME work to do in this area. It might be best to always use 'it is an error' and then somewhere in the spec say what WSDL processors must do when errors are encountered. This approach will only work if we want WSDL processors to have the same behaviour in the face of each and every possible error, of course. Gudge > -----Original Message----- > From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] > Sent: 07 November 2003 15:28 > To: Martin Gudgin; David Booth; Anne Thomas Manes; Mark > Baker; Glen Daniels > Cc: www-ws-desc@w3.org; paul.downey@bt.com > Subject: Re: What WSDL defines - the diagram! > > I agree with Gudge, but I thought the current wording of the > spec in component-model-speak rather than document-speak > achieves precisely this. If not can we not add more > conditions about the component model without talking about a > processing model? > > I'm not strictly opposed to adding a processing model, but > extending the current approach seems workable to me. > > Sanjiva. > > ----- Original Message ----- > From: "Martin Gudgin" <mgudgin@microsoft.com> > To: "David Booth" <dbooth@w3.org>; "Anne Thomas Manes" > <anne@manes.net>; "Mark Baker" <distobj@acm.org>; "Glen > Daniels" <gdaniels@sonicsoftware.com> > Cc: <www-ws-desc@w3.org>; <paul.downey@bt.com> > Sent: Friday, November 07, 2003 4:11 PM > Subject: RE: What WSDL defines - the diagram! > > > > > > It's not about a 'document'. It's about a set of WSDL > components. You > > can't tell by looking at a single document whether it violates the > > unique definitions rule. You have to follow imports to do > that, which > > is something only a WSDL processor can do ( whether that > processor is > > implemented in wetware, XSLT, Java or whatever ). > > > > So, I disagree that our job is only to state what it means to be a > > WSDL document. We do need to state that. But we also need to state > > what it mean to be a valid set of WSDL components. Note that the > > distinction here is EXACTLY the same as that between a > schema document and a schema. > > > > Gudge > > > > > -----Original Message----- > > > From: David Booth [mailto:dbooth@w3.org] > > > Sent: 07 November 2003 08:57 > > > To: Martin Gudgin; Anne Thomas Manes; Mark Baker; Glen Daniels > > > Cc: www-ws-desc@w3.org; paul.downey@bt.com > > > Subject: RE: What WSDL defines - the diagram! > > > > > > No, whether or not there are duplicate definitions is a > property of > > > the WSDL document -- not a question of what a WSDL processor does > > > with it. The > > > *document* is erroneous (or non-conformant) if it > contains duplicate > > > definitions. > > > > > > WSDL processors might do many things. We cannot make assumptions > > > about what they may wish to do, nor should we try to > restrict what > > > they might do. That's their business, not ours. Our > business is to > > > define: (a) what constitutes a conformant WSDL document; and (b) > > > what that document means. > > > > > > At 10:38 AM 11/6/2003 -0800, Martin Gudgin wrote: > > > >I think the WSDL 2.0 spec does define certain things that a WSDL > > > >processor MUST do. For example, check that no duplicate > definitions > > > >exist. > > > > > > > >Gudge > > > > > > > > > -----Original Message----- > > > > > From: www-ws-desc-request@w3.org > > > > > [mailto:www-ws-desc-request@w3.org] On Behalf Of David Booth > > > > > Sent: 06 November 2003 06:51 > > > > > To: Anne Thomas Manes; Mark Baker > > > > > Cc: www-ws-desc@w3.org; paul.downey@bt.com > > > > > Subject: Re: What WSDL defines - the diagram! > > > > > > > > > > > > > > > P.S. The greater significance of the diagram is not so > > > much in what > > > > > it includes but what it omits. In particular, it says > > > nothing about > > > > > what a WSDL *processor* must or must not do. > > > > > > > > > > There are different types of interoperability that we could > > > > > potentially strive to obtain with the WSDL 2.0 spec, > which I'll > > > > > arbitrarily call: > > > > > > > > > > Type 1: Web Service & Client interop. This type of > interop is > > > > > to ensure that the WS and client agree on the > mechanics of their > > > > > interaction -- the message formats, data types, > > > transport, MEP, etc. > > > > > (Of course, they still need to use other means to ensure > > > that they > > > > > agree on the semantics and other higher-level details of the > > > > > interaction -- beyond what WSDL covers.) > > > > > > > > > > Type 2: WSDL Processor interop. This type of interop > > > would ensure > > > > > that different WSDL processors would have the same > behavior when > > > > > presented with a given WSD. > > > > > > > > > > WSDL 2.0 pursues type 1: Web Service & Client interop. > > > It does not > > > > > define what a WSDL processor must or must not do with a > > > given WSD. > > > > > (And rightly so, in my opinion: what a processor *does* > > > with a given > > > > > WSD is its own business -- not ours.) > > > > > > > > > > > > > > > At 01:10 PM 11/5/2003 -0500, David Booth wrote: > > > > > > > > > > >Mark & Anne, > > > > > > > > > > > >Certainly, a WSDL document does not *fully* define client or > > > > > >service behavior, but it does *partially* define > their behavior. > > > > > That's what > > > > > >MEPs are all about. When a WSDL document specifies a > > > > > message exchange > > > > > >pattern, that pattern partially defines the behavior of the > > > > > interacting > > > > > >parties -- not their internal behavior, but their externally > > > > > observable > > > > > >behavior, i.e., what messages they send and receive and in > > > > > what sequence. > > > > > > > > > > > >The labels on the diagram were somewhat abbreviated, and > > > > > >omitted the word "partially". A clearer diagram is at > > > > > > >http://lists.w3.org/Archives/Public/www-archive/2003Nov/0002.ht > > > > > >ml > > > > > > > > > > > > > > > > > >At 01:34 PM 11/4/2003 -0500, Anne Thomas Manes wrote: > > > > > > > > > > > >>+1. > > > > > >> > > > > > >>WSDL explicitly does not define client or service > behaviour. > > > > > >>It describes syntax of messages and protocols used > to exchange > > > > > those messages. > > > > > >> > > > > > >>Anne > > > > > >> > > > > > >>At 10:41 AM 11/4/2003, Mark Baker wrote: > > > > > >> > > > > > >>>Cool, thanks for tackling that at the f2f. > > > > > >>> > > > > > >>>But I disagree with the diagram. As it was explained to > > > > > me, a WSDL > > > > > >>>2.0 document could be said to "describe the syntax" of > > > client and > > > > > >>>service ("schema in, schema out"), rather than "define the > > > > > >>>behaviour", which would require defining what > in/out means in > > > > > >>>relation to any requested semantics (aka the protocol). > > > > > >>> > > > > > >>>WSDL 1.1 describes the protocol in that it suggests that a > > > > > successful > > > > > >>>response to a message means that the requested > > > operation in the > > > > > >>>message was successfully invoked. WSDL 2.0 is ambiguous. > > > > > >>> > > > > > >>>Mark. > > > > > >>>-- > > > > > >>>Mark Baker. Ottawa, Ontario, CANADA. > > > > > http://www.markbaker.ca > > > > > > > > > > > >-- > > > > > >David Booth > > > > > >W3C Fellow / Hewlett-Packard > > > > > >Telephone: +1.617.253.1273 > > > > > > > > > > -- > > > > > David Booth > > > > > W3C Fellow / Hewlett-Packard > > > > > Telephone: +1.617.253.1273 > > > > > > > > > > > > > > > > -- > > > David Booth > > > W3C Fellow / Hewlett-Packard > > > Telephone: +1.617.253.1273 > > > > > > > >
Received on Friday, 7 November 2003 10:56:05 UTC